The following forum(s) are migrating to a new home on Microsoft Q&A (Preview): Developing Universal Windows apps!

Ask new questions on Microsoft Q&A (Preview).
Interact with existing posts until December 13, 2019, after which content will be closed to all new and existing posts.

Learn More

 none
[UWP] Background audio intrerupted when application starts up after being closed by user/system RRS feed

  • Question

  • Nicely reproducible with the background playback sample from github

    1) Start playback.

    2) close app from task manager -> sound doesn't stop with debugger attached, stops otherwise.

    3) start app -> sound stops.

    Sounds like the good old 2 process approach is better after all...


    • Edited by mcosmin Sunday, August 7, 2016 10:29 AM
    Sunday, August 7, 2016 10:11 AM

All replies

  • This is by design. Explicitly closing an app stops the process and is supposed to stop playing audio. This is not different than any other platform.

    Explicitly terminating a process should never continue to use system resources, including playing audio.

    There is a difference between explicitly terminating an app as you have done, implicitly terminating an app due to system policy, and suspending an app due to system policy.

    Background audio is specifically *not* closing an app and letting the process continue to run and play music in the background--neither suspending nor terminating.

    Sunday, August 7, 2016 5:56 PM
  • then why xbox music is not playing by this rule? maybe because it uses 2 process?

    This is a huge let down for many audio apps, because users will compare to xbox music which does not have this problem. I know a lot of people will queue something then force close the app to "save resources".

    Unless the 1 process approach emulates this, developers will have a hard time adopting it, because nobody wants to have 1 star reviews because you do stealth changes to your system.

    Sunday, August 7, 2016 6:07 PM
  • We just finished updating the platform. It takes time to update apps after; that one isn't yet.

    As I explained, the fact that audio stops playing when you terminate a process is not a problem, it's by design. Xbox Music continues to play because you didn't terminate the process that was playing audio.

    In any case, single process apps are designed to release memory when they're running in the background. There is no need for users to attempt to micro-manage this as the app is already doing the equivalent of releasing resources that a foreground process would have held onto in the multi-process model.

    Single process background playback was a direct result of listening to feedback from customers and from developers building media apps.

    We worked closely with partners to build a great experience, and if we need to make improvements, we will continue to tune the platform to serve our customers based on their feedback.

    Sunday, August 7, 2016 6:54 PM
  • you are wrong about xbox music. If i do the following on xbox music

    1) start playback

    2) force kill with task manager (this is on phone btw), xbox music will NOT stop playing.

    if I do this with my app, it WILL stop playing.

    This automatically puts my app at a disadvantage, because users will think it is broken, since many of them are used to do this pattern.

    If I do the same with VLC, which also uses 2 process, it will behave exactly like xbox music. People WILL use this as a way of comparing performance between apps. If you're gonna do this, you better document in OS changelogs or adopt your xbox music to the same approach, otherwise people WILL downvote apps, because they do not care if I use a 1 process approach or a 2 process approach. If I publish my updated app tomorrow, it will probably be the single app in the marketplace that has 1 process approach, and everybody will think it is broken, since all other apps behave the same.

    So either make the 2 process approach also shut down when the app is force closed, or make the 1 process approach behave like the 2 process approach.

    And users don't know the difference between force close or being closed by the system. If they notice playback doesn't stop after app was closed by system, they will think there is some sort of bug in my app after they force close it.



    This design makes sense on a PC where you can hold apps in memory forever. On phones, once the foreground process is consumed by other apps, this becomes extremely confusing for the average user, because he can't even force close the app anymore to stop the music, which seems to be your primary design goal.
    • Edited by mcosmin Sunday, August 7, 2016 7:42 PM
    Sunday, August 7, 2016 7:27 PM
  • I said, "Xbox Music continues to play because you didn't terminate the process that was playing audio."

    This is true. You terminated the foreground process. The foreground process is not the one playing audio, the background process is and it has an independent lifecycle.

    You said, "This automatically puts my app at a disadvantage, because users will think it is broken, since many of them are used to do this pattern."

    It's unfortunate that some users would have felt they needed to tune the system to this level by force-terminating applications, because the platform is designed to take care of this on its own. Ideally closing an app from the shell would have terminated both the foreground process and the background process, and then this wouldn't have been perceived as some kind of performance hack; that just wasn't an important distinction at the time.

    We may change that behavior in the future, but as we expect apps will be converting to single process (including our first party apps), this is a short-term difference between apps that will be self-correcting.

    If you really like the multi-process approach, you're free to use it this release just like any of these other apps that haven't converted yet. But be aware that single-process is the recommended path forward and it's very likely multi-process could be deprecated at some point.

    Sunday, August 7, 2016 7:51 PM
  • It is not that I overly like the 2 process approach, but it seems to be providing what the users expect it to be.

    I will keep waiting for xbox to update to 1 process before I will do the same, I don't feel like ruining my rating with this new stealth change.

    Monday, August 8, 2016 6:23 AM
  • I'd be interested to review the data you have showing user expectations. In particular it would be great to learn why your users felt it was necessary to manually close the app process in the first place to "save resources". The system is designed to suspend or terminate the process itself if it needs the resources. And to be clear, there is no "stealth change" here. Terminating a process has always stopped the audio that process is playing. Audio only continues in the multi-process model because there is no way to terminate the background audio host from the task manager on Xbox and Phone.
    Monday, August 8, 2016 8:48 AM
  • It is not necessarily my users.

    You see, in windows 10, a lot of first party and third party apps have turned into battery chewers with the new extended execution session. Particularly microsoft health and the various facebook apps.

    These apps will chew through battery, and users will end up checking in the battery saver where's what. Then they will notice these apps used a lot of battery in the background.

    Now, when they think of background, they think of apps staying in the task switcher, so it is this predisposition to clear apps to ensure they will not chew their battery. This comes from other OSes, like windows on laptop with old win32 apps, or even users that happen to cross from android to windows phone. Then they will develop the sense of killing apps once they are done with them and they will do the same with all apps.

    If you remember correctly, the feature which allows users to force close on phones was develop specifically because some apps continue to run in the background forever unless they are stopped. The main reason back then was here drive + eating battery on windows phone 8, unless it was completely cleared from memory, so the close button was invented.

    Now, if users are using groove/xbox music or VLC or any other old app in the store and they are not happy about it, they will try my app, and they will apply this behavior to close apps. You can check pretty much any user group of windows phone (I do not have store data since my app still uses WP8.1) and you will see a lot of battery saving tips revolve around force closing apps, which in some cases does make a difference (again, facebook and microsoft health) and users will force close everything thinking the evil developer has this hidden time bomb to chew their battery.

    Then they will see my app stops playing music and they will think "oh crap, this app needs to run in background it will ruin my battery omg omg omg quick uninstall uninstall uninstall" and also throw in a 1 star review for good measure. And then if you have a heavy battery usage feature like a jukebox which needs to support files that are not indexed by the system and you drain a good fare of battery when in the foreground to create your own index (see VLC), you are doomed to stay at the rock bottom of the store rating, even though it is not your fault.


    As I have said in another thread, it would be great if the app would stay in the task switcher even when its actual memory was claimed by other apps. This way the users has a way of knowing the app is there and playing, and that if they close it, they will lose the audio no matter what. The users are not tech savvy enough to know the difference between suspension, terminated by system, force closed by user or app crash, they will just see them as the same thing. If the app is suddenly gone from task switcher because another app needed its memory, the user will think it is OK for it to run in background, but if he force closes things get funky.

    • Edited by mcosmin Monday, August 8, 2016 9:46 AM
    Monday, August 8, 2016 9:40 AM