Integrate BackgroundAudioPlayer and XNA MediaLibrary
Allow the BackgroundAudioPlayer to play tracks from the MediaLibrary. Or allow applications that implement the XNA MediaPlayer class to run in the background.
zl1
shared this idea
Thank you for the suggestion. We are not adding this capability in the 8.0 release, but know that it is high on the consideration list for future Windows Phone releases.
Keep those suggestions and votes coming!
3 comments
-
Lassi Kinnunen commented
this is a vital addition. just add the possibility to add a Song object to be played by the backgroundaudioplayer.
this is standard expected functionality from the api-set.
-
Anonymous
commented
In trying to develop a custom playlist application, it is apparent that it is impossible to integrate the BackgroudAudioPlayer with the XNA.MediaLibrary. This means that applications that wish to use the capabilities of the BackgroundAgent are restricted to using only local audio files that are deployed with teh application, or audio streaming sources. There is no way to access the phone's MediaLibray.Songs to have the BAP play these files in teh background. This is highly restrictive because we can only use the MediaPlayer for foreground applications. Unless of course we go with a predetermined SongCollection such as SongCollection limitedPlaylist = new MediaLibrary.Songs; This stops the ability to create custom playlists.
There are really a number of ways MS could address this limitation:
1. Expose the SongCollection class so we can add and remove song objects from custome song collections. This way we can pass the entire SongCollection object to the MediaPlayer.Play() method, and providing we don't stop the MediaPlayer, the entire playlist will continue to play despite other foreground applications running.2. Allow the BackgorundAudioAgent to utilise the XNA framework so that the device's song library can be played and manipulated from the background. You would also need to provide a conversion mechanism to convert a Song to an AudioTrack - as is the default file type for the BAP.
3. Relax the restrictions around application running under a locked screen and/or in the background. So long as the user must explicitally accept the use of teh app in the background, then why is it an issue. Users understand the additional strain this would potentially put on battery life, but by accepting they agree that it's okay.
These are only my suggestions, there may be smarter ways to achieve this, but in the end, the current functionallity is pointless.
-
Anonymous
commented
In trying to develop a custom playlist application, it is apparent that it is impossible to integrate the BackgroudAudioPlayer with the XNA.MediaLibrary. This means that applications that wish to use the capabilities of the BackgroundAgent are restricted to using only local audio files that are deployed with teh application, or audio streaming sources. There is no way to access the phone's MediaLibray.Songs to have the BAP play these files in teh background. This is highly restrictive because we can only use the MediaPlayer for foreground applications. Unless of course we go with a predetermined SongCollection such as SongCollection limitedPlaylist = new MediaLibrary.Songs; This stops the ability to create custom playlists.
There are really a number of ways MS could address this limitation:
1. Expose the SongCollection class so we can add and remove song objects from custome song collections. This way we can pass the entire SongCollection object to the MediaPlayer.Play() method, and providing we don't stop the MediaPlayer, the entire playlist will continue to play despite other foreground applications running.2. Allow the BackgorundAudioAgent to utilise the XNA framework so that the device's song library can be played and manipulated from the background. You would also need to provide a conversion mechanism to convert a Song to an AudioTrack - as is the default file type for the BAP.
3. Relax the restrictions around application running under a locked screen and/or in the background. So long as the user must explicitally accept the use of teh app in the background, then why is it an issue. Users understand the additional strain this would potentially put on battery life, but by accepting they agree that it's okay.
These are only my suggestions, there may be smarter ways to achieve this, but in the end, the current functionallity is pointless.
