microsoft / Windows-universal-samples

API samples for the Universal Windows Platform.
MIT License
9.53k stars 7.97k forks source link

BackgroundMediaPlayback Audio Stops if App is Removed From Background #491

Closed iamsid closed 8 years ago

iamsid commented 8 years ago

I am updating my UWP music player app (Music Wall) to integrate the new BackgroundMediaPlayback system in the AU 1607.

Earlier

Earlier I was using a background task and managing playlist using a shared project. There are numerous issues with the older method, but I implemented workarounds and exception handling and the app on store is stable and works well on all Windows 10 versions before AU.

With the change in AU, if the app is kept idle with music paused for a few minutes, the background player crashes. Although my app does not crash, but I have to exit & restart the app to start playback again.

Hence, I decided to create a separate version targeting only the AU version. The implementation for background audio is pretty easy compared to the "Legacy" method.

With AU on Mobile (10.0.14393.221)

While most of the stuff is working great on both Desktop & Mobile, the background part is confusing me. The sample & my app, both work well in foreground and background. As soon as I remove the app from background/multitasking or suspend using VS, the playback stops. But, Groove manages to continue playing audio in background even after app is removed from background. From what I have read, latest Groove version uses the new background audio model.

Is there something missing from the sample & my app that is preventing the audio to flow in background? Or, is this the expected/normal behavior in this new system? If yes, then how is Groove doing it (any ideas)?

aarononeal commented 8 years ago

The legacy 2-process model by design cancels your background task after a few minutes if left paused. It's also possible for the foreground app UI process to be suspended or terminated as well. They have independent life cycles. Most likely your app appears to crash because you attempt to communicate between processes and don't handle the resulting exception when one is missing. All calls to BackgroundMediaPlayer can throw RPC exceptions and this must be handled. This is complex and one of the reasons we recommend the single process model in the AU.

The behavior you see in the single process model on AU is also by design. If you suspend or terminate the app process, it is supposed to stop playing. Processes are never allowed to retain system resources, audio or otherwise, when terminated. The reason you don't see this same behavior with legacy 2-process apps is due to a limitation in the current shell where we're only terminating the foreground process and not the linked background process. That may be corrected one day as it is not desirable to keep playing after a user has used the shell to terminate an app. The AU design is our target.

Groove is still using 2-process on some platforms and is in the process of converting.