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][C#] MediaPlaybackList memory leak RRS feed

  • Question

  • Hey,

    a while ago I had this weird issue that after some time my background task would just quit because he had insufficient memory to continue.
    I think I found the issue now.

    First a little bit of detail:
    I am using a custom class that implements the IRandomAccessStreamReference interface.
    Using this class I create MediaSources which I then wrap in a MediaPlaybackItem and add to a MediaPlaybackList.
    When OpenReadAsync() is called I call an async Task method that actually opens the file and the stream and returns it.
    I cast the Task<> to AsyncOperation with AsAsyncOperation() and return it.

    So now here's the problem:
    When going through the playlist (for speed reasons i just moved to the next one all the time and didn't wait for each track to end) I noticed that the memory usage is constantly rising.
    Just 1-4 MB per track but it all adds up until the memory limit is reached. I can set a higher limit (did try until 100 MB which was still successful on a lumia 650 with 1 GB RAM) but that's obviously not a viable solution.

    I worked out a little workaround:
    In the CurrentItemChanged handler I simply Reset the MediaSource Source of the OldItem (if it isn't null).
    That way the memory remains relatively constant +/- 2MB

    So I'm wondering did I do something wrong (and made it impossible for the MediaPlaybackList to free the memory by itself) or is there a bug in the MediaPlaybackList?

    Thursday, April 21, 2016 4:03 PM

All replies

  • Hello St3f4n,

    To know whether this is a known issue we need to reproduce your problem. Would you mind to send a simple repro sample?

    And please make sure you've canceled some possible resource like described here:

    https://blogs.windows.com/buildingapps/2016/01/13/the-basics-of-background-audio/

    See Cancellation Callback here.

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, April 22, 2016 4:48 AM
  • You are probably using C# for your background task. In my experience, it is time to move on. The .net framework that runs on phones is simply too lazy to clear memory in time. Your behavior with +/- 2 MB of memory usage is a pretty good description of the GC kicking in at some point to clear stuff.

    If you want fine tuning of memory management it is time to go for C++/CX.

    I would also not use the MediaPlaybackList, if you want advanced stuff you're going to have to do this on your own, from scratch.

    Friday, April 22, 2016 6:22 AM
  • Actually I think it's a lot more likely that the +/- 2MB are due to different sizes of the music files.
    And with a memory consumption of around 18 MB for the background task I would say it's not much of a problem.

    Care to elaborate on why I shouldn't use MediaPlaybackList?
    Apart from this memory leak it works pretty good.

    @Barry I think I'm handling the cancellation callback correctly but even if not I don't think it plays a role since the task isn't cancelled until the memory exceeds the limit.

    Don't know when I'll have time to create a sample but I'll try.
    Friday, April 22, 2016 11:49 AM
  • +/- 2MB should not come from different file sizes. The buffer size is determined by the encoding properties (i.e how big the samples are), not how big the file is. If you see a 2MB difference between files of same encoding, you are most likely dealing with a memory leak somewhere (or a lazy GC).

    Friday, April 22, 2016 1:43 PM
  • I can confirm, there is either memory leak or some other issue with MediaPlaybackList causing OutOfMemoryException. At least I saw it trying to port my WP 8.1 app too.
    Monday, April 25, 2016 3:24 PM
  • @St3f4n,

    OK I think I need to wait for the sample. Can I know your OS version number and your target SDK version of your app?

    @Username already in use

    If you also have the same problem do you have any sample or any exist apps which can reproduce this issue?

    If this is the API problem, to report this kind of issue for you guys, I need to reproduce it first.

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    • Edited by Barry Wang Tuesday, April 26, 2016 9:02 AM
    Tuesday, April 26, 2016 9:02 AM
  • Sure, I'm getting some new hardware today but hopefully when I'm finished and on a clean, fresh Windows I'll find some time to make a sample.

    'till then my OS version is 1511 build 10586.218 and my app is minimum 10240 and the target is 10586 I believe. 

    Tuesday, April 26, 2016 9:17 AM
  • @St3f4n,

    Thanks for the details.

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, April 27, 2016 6:41 AM
  • I've created a sample.
    How would you like me to send it to you?
    Thursday, April 28, 2016 1:56 PM
  • @St3f4n,

    What about use OneDrive? I'm not allowed to share my email here for security reason. But if you don't want to use OneDrive, I will help you consult how can we receive your project.

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, April 29, 2016 1:30 AM
  • OneDrive is fine. The project is on there anyway.
    Click me.

    Use music files from your music library. MP3, M4A and FLAC are supported in the filetypes filter but feel free to add others.
    Tried it only with mp3 though. In the BackgroundTask there is a const CloseOld. If you set it to true the old source is closed when the item is changed which seems to fix the memory leak.
    • Edited by Stefan Fabian Friday, April 29, 2016 12:17 PM made link link
    Friday, April 29, 2016 12:16 PM
  • Hi Folks, once items are opened in the list we keep them active (user may return to the previous track, etc.) and it's currently up to the app to reset sources that are no longer needed by calling MediaSource.Reset().
    https://msdn.microsoft.com/en-us/library/windows/apps/windows.media.core.mediasource.reset.aspx
    We're looking at options to make this configurable on the list and start with some reasonable defaults in a future update.
    Thursday, May 12, 2016 1:31 AM
  • wouldn't it be sufficient to keep the previous and the next one? or the previous two and next two?
    I mean it's not a normal usage scenario that someone is going back multiple times and even if they do they usually don't expect gapless playback anyway.
    There's also some issue that the playback just stops. It says it is still playing but it's not. Pausing and pressing play usually fixes it.
    This only happens when a new track starts.

    Thursday, May 12, 2016 8:04 PM
  • Thanks for the feedback. Yes, for most apps. I expect we'll implement a one or two item history as the default in the future. Does your sample app above reproduce the stop issue you're seeing? I'm not observing that here and recently ran a 24 hour test with our background audio sample on Github.
    Thursday, May 12, 2016 9:03 PM
  • You're welcome. Sounds good.
    No, I couldn't reproduce it. It's very random and only happens on my phone (lumia 650). I only know that it's not the tracks that cause it because sometimes it happens and sometimes it doesn't with the same track.
    Thursday, May 12, 2016 9:23 PM
  • There was this bug where normal background playback would stop on Windows 10 Mobile after 2-3 tracks. I had this with normal playback but I think it also affected MediaPlaybackList, it's probably what St3fAn has also experienced. That bug was fixed with one of the latest W10M updates (also on release branch, not only TH2), at least for normal playback I can confirm that it is fixed (I have not tested MediaPlaybackList).
    Thursday, May 12, 2016 9:26 PM
  • Probably not my issue. It still persists on 10586.318 which is the latest non-insider release.
    It's also not just after 2-3 tracks. Today it stopped after 1 track then it ran for 2-3. After that around 2 Tracks and then I think 1-2.
    The last time the new track was played for a fraction of a second before playback paused.
    Saturday, May 14, 2016 1:07 PM
  • Right now it's hard for me to tell if this is a content, app, or platform issue you're experiencing. To help diagnose, you could try the BackgroundAudio sample as is and let it run for an extended period of time to see if it still occurs, both with its existing content and replacing the content with what you're seeing the issue with.

    Audio pausing on mobile is often due to the app going over the background memory limit causing either the app or background task to suspend or cancel. The two can happen independently so it's easy for an app to get out of sync if not handled correctly.

    We've made major updates to the background playback architecture in the "Anniversary Update" so that apps can play media in the background from a single process instead of the dual process approach, and this avoids a ton of state syncing complexity. The latest Insider release and SDK has these if you're interested.

    Saturday, May 14, 2016 4:51 PM
  • Right now it's hard for me to tell if this is a content, app, or platform issue you're experiencing. To help diagnose, you could try the BackgroundAudio sample as is and let it run for an extended period of time to see if it still occurs, both with its existing content and replacing the content with what you're seeing the issue with.

    Audio pausing on mobile is often due to the app going over the background memory limit causing either the app or background task to suspend or cancel. The two can happen independently so it's easy for an app to get out of sync if not handled correctly.

    We've made major updates to the background playback architecture in the "Anniversary Update" so that apps can play media in the background from a single process instead of the dual process approach, and this avoids a ton of state syncing complexity. The latest Insider release and SDK has these if you're interested.


    Can you please post a blog entry or something that explains the differences in the anniversary update?
    Sunday, May 15, 2016 7:17 AM
  • Right now it's hard for me to tell if this is a content, app, or platform issue you're experiencing. To help diagnose, you could try the BackgroundAudio sample as is and let it run for an extended period of time to see if it still occurs, both with its existing content and replacing the content with what you're seeing the issue with.

    Audio pausing on mobile is often due to the app going over the background memory limit causing either the app or background task to suspend or cancel. The two can happen independently so it's easy for an app to get out of sync if not handled correctly.

    We've made major updates to the background playback architecture in the "Anniversary Update" so that apps can play media in the background from a single process instead of the dual process approach, and this avoids a ton of state syncing complexity. The latest Insider release and SDK has these if you're interested.


    Can you please post a blog entry or something that explains the differences in the anniversary update?

    +1

    And also it would be nice to know which way is the recommended way.
    Is the two process architecture still supported or is it deprecated?
    Does it have any noticeable advantages like better battery usage or anything like that?
    I mean there's gotta be a reason why it was introduced in Windows 10 other than being a pain in the ass for devs.

    Sunday, May 15, 2016 11:12 AM
  • Wow, at last this nightmare will end, thank you very mach! When it will be ready it would be nice to have some guidance about migration from old architecture to new. I mean, some recommendations how to support both architectures for old and new versions of Windows 10 in one app.

    About issue with player stopping after 2-3 tracks:

    I have it too. I do not use MediaPlaybackList keeping tracks in simple LinkedList instead, on MediaEnded I use SetFileSource to change track. In this scenario sometimes playback does not start, so as workaround I even added timer with following callback:

            private void CheckIsPlaying(object state)
            {
                if (!new[] { MediaPlayerState.Buffering, MediaPlayerState.Opening, MediaPlayerState.Playing }.Contains(Player.CurrentState) || Player.Position < TimeSpan.FromMilliseconds(200))
                {
                    try
                    {
                        if (Player.CanPause) Player.Pause();
    
                        Player.Play();
                    }
                    catch (Exception e)
                    {
                        Controls.DisplayUpdater.MusicProperties.Artist = e.Message;
                    }
                }
                else
                {
                    PlaybackBugWorkaroundTimer.Dispose();
    
                    PlaybackBugWorkaroundTimer = null;
                }
            }

    Sunday, May 15, 2016 11:33 AM
  • Since we are on the topic of sharing frustruations with the background audio in windows 10 mobiles, here's mine

    Some users reported tracks stopping after 3-4 tracks for my app too. In my case, I never actually observed this behavior on my phone, which is enrolled in the release branch , so it must be for the users running the redstone dev preview. My app does not have the luxury of using a linkedlist, or using the mediaplayback list or whatever list. It uses a custom made system for fetching tracks that are saved in a database, and only 1 track is ever in memory at any given time. Everything is in C++/CX, has deterministic memory management, therefore, I hardly doubt this system would leak memory at all. it does not leak at all on windows phone 8.1 and it has been running for over 1 year now. This is obviously a problem on your end.

    Speaking of problems on your end, there is absolutely 0 serious documentation on how to get background audio working properly. The sample is well, just a sample, and it is in C#, which you yourself advised not to use for background tasks due to undeterministic GC causing memory leaks.

    Now you speak of some alienish "lifecycle" for background audio tasks that have literally 0 documentation anywhere.

    What is the difference between the background audio task getting closed and getting suspended?

    How do you register for this mythic "suspension"event?

    How do you properly keep state in sync?

    I always had the feeling that Microsoft doesn't really take background audio seriously. With architecture changes every 1 year, this is rather getting old and tiresome. Please provide some *proper* documentation on what is going to change, what has changed already since 8.1, and how to properly handle the BAP on W10M.

    Meanwhile I will delay the release of my app on UWP a few more months, until you figure things out.

    Yeah, the problem also occurs with 8.1 compiled apps running on W10M, so the issue is clearly on the system side, not in the SDK, nor in the apps themselves.
    • Edited by mcosmin Sunday, May 15, 2016 2:10 PM
    Sunday, May 15, 2016 2:06 PM
  • First let me say, we hear you. Background audio with the 2-process architecture from Phone 8.1 and carried over to Win10 UWP is not easy for app developers to use. This is why we invested in improving this area for the Anniversary Update, and our solution is inspired by the single process architecture we supported on desktop but could not take everywhere until now. So let me try to clear up a few things.

    Memory leak

    This thread is misnamed. There is no leak at play here from what we've discussed so far and the playlist is operating as designed with apps owning the responsibility to close items according to their cache rules. You can argue it's not an optimal design to keep list items open by default, and as I said, that's good feedback and it's likely we'll change that default behavior in the future.

    C# vs C++

    There is no need for a language debate. Both are fully supported and both can be used to write great apps. It's not closing items that's driving up memory usage here and that has nothing to do with language choice.

    Player pausing

    There are reports of the player pausing unexpectedly on this thread. There are too many variables, so without a repro project and content it's going to be challenging to identify a root cause. For folks hitting this, are you also subscribing to the MediaFailed event? Or if using a MediaPlaybackList you need to check ItemFailed. This would tell your app if you've hit a content problem, network problem, etc. Do you have AutoPlay set or do you call Play() manually? Do you see these same pauses using our sample apps with and without your content? There may be an issue for us to resolve, but we need to be able to reproduce it first.

    Dual process

    The reason for dual process and its origin on Phone is that device resources are finite. Keeping audio running on a 512MB phone with apps and other background services meant that background audio apps needed to stay under certain memory quotas. In this case, around 35MB.

    At the time, the best solution available to keep apps under that quota was to allow developers to split their app into a UI process and a background process so that the memory heavy UI process could be removed from memory independently from the background process.

    That of course meant app developers had to deal with additional complexity to keep these processes and their state in sync. While not ideal, to be perfectly frank, it was either this solution or no solution at the time.

    The existing 2-process documentation for UWP is here for folks having trouble locating it:

    https://msdn.microsoft.com/en-us/windows/uwp/audio-video-camera/background-audio?f=255&MSPPError=-2147217396

    It's a good high-level overview of the various components in play and even includes an architecture diagram, which if nothing else, shows that it's a pretty complex approach. There are several paragraphs there explaining the lifecycle and various events an app needs to handle.

    We have an implementation of this guidance in the sample on GitHub:

    https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/BackgroundAudio

    General guidance on UWP lifecycle is here:

    https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

    And also covered through various venues such as:

    https://visualstudiomagazine.com/articles/2015/09/01/its-universal.aspx

    So, the questions on thread about app lifecycle seem to be fairly well covered by our docs. The fact that it's hard, well, that's why we're improving it.

    One Process in the Anniversary Update

    We talked very briefly about the new "one process" model at //build in these 2 talks:

    https://channel9.msdn.com/events/Build/2016/B817

    https://channel9.msdn.com/events/Build/2016/B876

    Since then we've hit feature complete and have more to share, but please keep in mind we're still talking about a pre-release. Docs and blogs will follow in due course.

    Here is an overview in the interim:

    • You can enable background audio with a new manifest capability.

    <Package

      xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"

      xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"

      xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"

      xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"

      IgnorableNamespaces="uap uap3 mp">

    . . . .

      <Capabilities>

        <Capability Name="internetClient" />

        <uap3:Capability Name="backgroundMediaPlayback"/>

      </Capabilities>

    </Package>

    • This changes lifecycle behavior to keep your process from suspending as long as you are still playing audio. All streams become background capable so they don't mute. 
    • All audio APIs become background enabled when you opt-in with this capability. That means now you can use any of our audio APIs, such as MediaPlayer, AudioGraph, XAudio2, HTML Audio tag, etc. 
    • If you need to perform background logic when you're not playing audio, use Extended Execution or ApplicationTrigger. The first //build talk above covers this, but handling triggers and running background tasks in-proc is much easier through the OnBackgroundActivated handler.
    • CoreApplication has new lifecycle events EnteredBackgroundLeavingBackground that your app can use as a trigger to shed memory.
    • We've relaxed the over limit policy. Instead of terminating the app immediately, apps continue to run while over target so long as the OS doesn't need the memory. Apps can improve their priority by keeping usage low when backgrounded.
    • MemoryManager has additional members to tell you how your app is doing, and AppMemoryUsageLevel has a new OverLimit value to tell the app if it's over so it can do something about it. If the app wants, it can unload its UI like 2-process, but more easily, by setting Window.Current.Content = null.
    • When the app backgrounds or receives an over limit notification, platform frameworks will do what they can to shed unused resources, such as cached textures.
    • MediaPlayer has been promoted. It works in foreground and background apps, with UI or without. All key media features from MediaElement have been integrated into it. Now you can "new MediaPlayer()" anywhere.
    • A new lightweight MediaPlayerElement has been added to support binding and unbinding to a player for displaying video. This new design finally allows us to support background video since rendering to an element is decoupled from the player and it allows background audio apps to leverage platform media controls if desired.
    • MediaPlayer has a new MediaPlayerSurface that can be used to render video to a Windows.UI.Composition surface. In addition to enabling media playback in "framework-less apps", since all XAML elements are backed by these surfaces, you can render video to any XAML element.
    • MediaPlayer now has built-in connectivity to SystemMediaTransportControls through a new CommandManager so that you get these controls basically for free. No more implementing ButtonPressed, etc. These controls are important because that's how the app responds to HW button presses, Bluetooth, etc. and are required for background audio.
    • MediaPlaybackItem has new DisplayProperties that you can populate with artwork, track title, etc. and we'll update system controls automatically when the item is playing.
    • Media item tracks expose additional properties for track metadata properties, codec discovery, etc.
    • MediaPlayer now as a MediaBreakManager and MediaPlaybackItem has a BreakSchedule for ad or other content insertion.
    • MediaPlayer allows apps to play to specific endpoints if needed via AudioDevice.
    • MediaPlayer supports a MediaTimelineController that can be used to synchronize content across multiple players.
    • MediaPlayer now allows control of the source video rectangle which makes it possible to implement hardware efficient panning and zooming.
    • Background casting has been enabled for both dual and one process models.
    • AudioGraph adds emitters and listeners for spatial audio.
    • You can continue to use dual process on older versions of Windows and the new one process model on new versions, and you can do this from a single binary using adaptive versioning techniques: https://blogs.windows.com/buildingapps/2015/09/15/dynamically-detecting-features-with-api-contracts-10-by-10/
    • Migrating entirely from two to one process largely comes down to removing all the old code you were using to sync state across processes. Some apps will still want to keep their background playback decoupled from UI so in low memory situations can unload their view (though many apps just won't need to anymore). This is fairly straightforward now that MediaPlayer can bind and unbind to a MediaPlayerElement.
    • We have more samples and docs on the way. These are generally created after feature complete and made available around the timing of the public build, though we do aim to get early versions out to Insiders when we can.

    Final thoughts

    I hope it's clear that we hear and value your feedback, we do think media and background playback are important feature areas, and with your support we will continue to make improvements over time. I think we've made substantial progress in the Anniversary Update and hope you do too.

    Sunday, May 15, 2016 8:25 PM
  • Thank you very much for the update. That sounds great!
    Is there an event for the over memory limit property?
    Or maybe even an event for when the OS needs more resources so we can unload the UI if and only if it is necessary?
    Sunday, May 15, 2016 8:42 PM
  • Thanks for the answer.

    C# vs C++

    We have to agree to disagree. It can be proven quite easily that background tasks written in C# have higher memory footprint than the ones written in C++. Simply create an empty background audio task in each language and monitor memory consumption. The C# one will have by default about 4MB higher footprint due to CLR host.

    Player pausing

    The media failed event rises sometimes when there are random internal errors in the background audio pipeline that do not affect playback at all, especially when using media stream sources, so I do not use it for anything of the like. This has worked perfectly fine on WP8.1 for well over a year.

    I call Play() manually because sometimes I have to support scenarios that are not supported out of the box by the system and have to manually control the playback start.

    Lifecycle

    It is not about the lifecycle of the foreground app, but rather the lifeycle of the background process, which you mentioned can be suspended. No such thing as background task suspension is mentioned for background audio.

    Audio pausing on mobile is often due to the app going over the background memory limit causing either the app or background task to suspend or cancel. The two can happen independently so it's easy for an app to get out of sync if not handled correctly.

    Single process approachSo basically, the way I understand it is that the single process background audio will only keep playing as long as the memory is not needed by some other app right?

    Whereas the 2 process approach will keep playing regardless of what happens with the foreground app memory usage, because it has a specially allocated memory which is not available to foreground apps anyway.

    Build videos

    I always find videos to be difficult to follow, because I would have to seek back and forth. All these things should be written down in articles that are properly tagged so they are easy to find using SE.

    Sunday, May 15, 2016 8:45 PM
  • Is there an event for the over memory limit property? Or maybe even an event for when the OS needs more resources so we can unload the UI if and only if it is necessary?

    Yes, most of these are already available through MemoryManager here. See AppMemoryUsageLimitChanging, AppMemoryUsageIncreased, etc. The main difference is 'Limit' is more of a target now, and AppMemoryUsageLevel which you can query any time (or during one of those events) gets a new OverLimit value.

    https://msdn.microsoft.com/library/windows/apps/dn633831?f=255&MSPPError=-2147217396

    Sunday, May 15, 2016 9:01 PM
  • Nice.

    Almost forgot the pause question. Thanks mcosmin for reminding me and btw I agree to his opinion on Build videos.
    Videos are nice but I prefer text articles not only because you can quickly reread a previous part but also because it's generally way faster to read an article than to watch a 60 minute video.

    BTT:
    I'm using AutoPlay but I've tried Play if I remember correctly. Didn't make a difference. I'm subscribed to ItemFailed but I don't think it's called.

    Sunday, May 15, 2016 9:19 PM
  • Lifecycle

    > It is not about the lifecycle of the foreground app, but rather the lifeycle of the background process, which you mentioned can be suspended. No such thing as background task suspension is mentioned for background audio.

    Foreground processes suspend (and then terminate), background tasks cancel. Cancellation is covered in these docs:

    https://msdn.microsoft.com/en-us/windows/uwp/audio-video-camera/background-audio?f=255&MSPPError=-2147217396

    https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/handle-a-cancelled-background-task

    https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/guidelines-for-background-tasks?f=255&MSPPError=-2147217396

    Single process

    > So basically, the way I understand it is that the single process background audio will only keep playing as long as the memory is not needed by some other app right?

    Whereas the 2 process approach will keep playing regardless of what happens with the foreground app memory usage, because it has a specially allocated memory which is not available to foreground apps anyway.

    No, we continue to prioritize audio apps above others. That said, devices have finite resources. If a user is trying to do something in a foreground app in a constrained scenario, the platform will always have to make trade offs.

    Sunday, May 15, 2016 9:19 PM
  • That still didn't really answer my question. So far it is a MAYBE we will stop music playback in at undetermined events, rather than NO, we will only stop at these specific events.

    So, the current 2 process implementation has the advantage that that little memory you have, it is yours regardless of what the user does in the foreground (which the exception of another music player starting playback in BAP, at which point that memory belongs to it).

    While I can see the single process attempt that as long as the system has enough memory, it will work, but as soon as the user starts messing around (i.e a game for example), that memory will eventually be claimed, and the music will, eventually, stop playing unexpectedly.

    is this correct? Can music in a single process setup, stop at unexpected times? Because the way I see it, the only way you could keep music going by hosting it in the "app space" memory is to not have it cleared from memory.

    So what I understood from you is...

    1) There is a way of having single process audio, which is simpler to implement, but it will stop working at unexpected time. This will most likely work perfectly fine on desktop PCs, because of extra RAM, but might be problematic on phones

    2) There is a more complicated way, 2 process audio, that will always keep playing, regardless of device.

    Monday, May 16, 2016 5:14 AM
  • No, that's not correct.

    Audio apps under target have the highest priority of any task type, equal to running in the foreground. This results in essentially the same guarantees whether one or two process.

    I encourage you to try out an Insiders build, and if it doesn't behave like you expect, we can look at our tuning.

    Monday, May 16, 2016 5:35 AM
  • Hey. Thanks for everything so far. Please bare with me some more.

    I will try an insider build as soon as I can. But I am still not convinced on one thing.

    Assume my music app is running in single process and uses X RAM.

    Then user wants to start EvillApp10, a poorly optimized app that devours RAM for a living (i.e facebook or instagram are good examples) and said EvilApp10 needs Y amount of RAM. Now if the system has Y amount of RAM to spare, it will run both my app and EvilApp10, this far I understood. But what happens if the system doesn't have Y amount of RAM to spare and my app has already shrunk all that it can shrink. Will that X be reclaimed to allow EvilApp10 to run? Or EvilApp10 will fail with OutOfMemoryException as soon as it claimed all the remaining RAM?

    Come to think of it: what happens if my app simply takes over the entire system RAM?

    Or is there still a reserved memory and no app can actually take over the entire system RAM? is the system "prepared" to handle 2 apps running at once?

    Sorry, I just see a few issues with this approach too ^^



    • Edited by mcosmin Monday, May 16, 2016 6:30 AM
    Monday, May 16, 2016 6:21 AM
  • Thank you for so valuable information, it is good to know that Anniversary Update will bring so many features (especially support of AudioGraph in background audio). In this light it seems that issue with pause is not so important, because anyway now I should rewrite my app.

     BTW, I believe that your team should have own blog to share such information officially in transparent and predictable manner.

    Monday, May 16, 2016 3:05 PM
  • Hi Aaron,

    thank you for the information on upcoming changes regarding background audio. I think that these are great news for devs of media related apps! When AudioGraph was introduced in Win1511, I was a bit shocked that is was not possible to use this in background. It was labeled as a new API to allow professional audio apps. But who is going to buy a "professional" audio app, if that app stops its playback just because it gets minimized? That just did not make any sense to me. Thanks for finally lifting this severe limitation, and allowing background playback for all media APIs. I also think that it makes sense to keep background player apps alive with the new "one process" approach. It is very common for users to regularly switch back to the player to change tracks. Starting from scratch after every app switch or phone unlock is a waste of resources and it is also a constant annoyance for users, having to wait for the "Loading..." screen to finish.

    About the pausing bug: The bug has already been confirmed and reproduced by a Microsoft dev (Franklin Chen) in this thread:

    https://social.msdn.microsoft.com/Forums/windowsapps/en-US/add7b2bb-b8d1-41be-bc27-2b6e2cf15a86/uwpbackground-audio-task-not-long-time-work-in-the-lumia-950950xl10586107?forum=wpdevelop#ad33d3ea-f81f-4b16-89d1-bc168d308ec4

    According to the last post in the thread, the bug is solved in 10.0.10586.218. I will re-test if I still see this still occurs on my Lumia 535 device. Maybe the bug is still in there, or it was only solved for some devices. Reading the other devs here, it looks like it is still not fully resolved. The general characteristics of the bug is this:

    - It only affects certain devices, not all devices. Confirmed on Lumia 950, 535, maybe others (830, 650)
    - It only happens when the screen is locked
    - It happens mostly after 3 tracks, but it can be a bit more or less
    - It is definitely not a bug in the app, it even happens on the WP81 BackgroundAudio sample when run on W10M!
    - The BMP starts playing a tiny bit of the track, then stops while still saying "Playing"
    - The BackgroundTask is still running, pressing pause then play will continue the track (no out of memory, no media error or anything like that)
    - When debugging, you can see that stop position is always > TimeSpan.Zero (but only few ms)

    @mcosmin: Even if C# has a GC, you can still free up your memory in a kind of deterministic way. After you set your window to "null" as Aaron proposed, just call GC.Collect() and all memory will be reclaimed instantly. As far as I know, even WP has a page file, so if your app does not do any additional work in the background (besides playing music), a lot of the RAM can be swapped out, if the foreground app requests so much memory. If another app misbehaves and eats RAM without limits, people will quickly notice this because the app will also often crash by itself. I would not worry too much about other apps misbehaving. Just make sure that your app plays nicely and you should be fine.


    • Edited by Lukas F Monday, May 16, 2016 7:55 PM
    Monday, May 16, 2016 7:54 PM
  • Hello Aaron,

    Sorry for asking again but would like to clarify certain information.
    I want to ask you if the coming update will fix my problem:

    1) I have a Socket connection (I must to use this type of connection) to the music stream and I change its content it in some way.  So I need to create new stream from modified arrays of bytes. For this I use custom IRandomAccessStream (as Source for BackgroundMediaPlayer.Current.SetStreamSource(...)) with implemented method:

    public IAsyncOperationWithProgress<IBuffer, uint> ReadAsync(IBuffer buffer, uint count, InputStreamOptions options)
            {
                return AsyncInfo.Run<IBuffer, uint>(async(cancellationToken, progress) =>
                {
                    progress.Report(0);

                    return await GetNewBytesFromStorage(count).AsBuffer(); //GetNewBytesFromStorage(count) - this method gets the needed amounts of bytes form circular storage
                });
            }
    I found a big memory heap for each new IBuffer container and I cannot controll or GC cannot collect all of them before the OutOfMemoryException fired. Circular buffer works without memory leak, - so my problem is in this part of code.

    Will the coming update fix it? 
    If it is my error, please, correct me or show the way how can I fix it. 

    2) I tried to use MemoryManager.TrySetAppMemoryUsageLimit(1024 * 1024 * 50) in Background component, but I got an error "{"Unable to cast object of type 'System.__ComObject' to type 'Windows.System.IMemoryManagerStatics3'."}". (https://msdn.microsoft.com/en-us/library/windows/apps/windows.system.memorymanager.trysetappmemoryusagelimit?cs-save-lang=1&cs-lang=csharp#code-snippet-1).

    3) What about increasing the limit of RAM for Background container at least to 50Mb?

    4) Can you say the approximate date of the above updates for background media playing?

    Thank you for your answers and your work.


    • Edited by Timaxoxa Tuesday, May 17, 2016 12:12 PM
    Tuesday, May 17, 2016 12:11 PM
  • @Lukas F,

    Any call to GC.Collect will NOT result in deterministic memory management. GC class should never be used in production code. This is a misconception among many C# programmers. There is no guarantee that memory will be freed at all when you call GC.Collect.

    If the frameworks will work properly, they should deterministically free memory when the frame content is null, because it breaks the ref between the process and the entire visual tree. Assuming the managed CLR releases the managed interop reference to the content, the content should self destruct. But there are a lot of variables at play here and I am not sure if setting the content to null will be enough, because the content classes might also have links to other objects in the tree that are fully managed (i.e your view models).

    So I think that in the end there will still have to be some sort of black boxing between the media player part of the app and the foreground app that can be shed. Because otherwise the media player module can keep the entire UI alive. The best way would be to write the logic in C++/CX for audio and have some sort of interface similar to the current background audio architecture so you won't be able to reference any UI part from the audio player part. I don't expect this to be any easier, in fact I expect to trade one problem (process syncing) with another (heavy duty memory management).

    Tuesday, May 17, 2016 12:27 PM
  • @mcosmin

    GC.Collect() does an immediate, full collection of all managed objects in all generations of the GC. So with this call, all objects that can be collected (no memory leaks assumed) will be collected, freed and the memory reclaimed. It is a rather expensive call, so don't call it if you don't need it. But it will sure do the job.

    Since you are developing a C# app, you probably have a lot of C# code connected to the UI (event handlers, value converters, etc etc). Just nulling out the window will not free up the UI (at least not all of it), because there are a lot of refs from your C# classes to the WinRT UI classes, keeping them alive. The UI stuff will only be freed up once all your C# classes have been collected. The UI and related objects are usually long living, so they will only be collected during the rare full GC collections, not during the more regular partial collections. Only calling GC.Collect() will ensure that all your objects are collected and the UI freed up. If you want to be extra sure, call GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(). Not sure if this is needed here though, usually GC.Collect() is all you need (do some tests if you are unsure).

    It is also wrong to say that GC should never be used in production code. Usually, the GC should not need to be used, most apps can live without it, and if you need to call it often, there is usually a problem with your app. But there sure are situation where it is wise to do a GC, that is, if you know better than the GC that a lot of memory is now up for collection, and/or there is a reason why you need to reduce memory consumption. And this is exactly such a situation: A lot of UI code is still in memory but it could (and should!) all be collected now. Here is a good discussion about when to use GC.Collect, pointing out some valid scenarios:

    http://stackoverflow.com/questions/478167/when-is-it-acceptable-to-call-gc-collect

    Tuesday, May 17, 2016 1:15 PM
  • It all depends on how well the CLR will handle the release of unmanaged resources, because technically, when you  go over the limit, the GC should start collecting stuff automatically, without that call.

    Tuesday, May 17, 2016 3:30 PM
  • I've found out something about the pausing bug.
    It also happens in the Groove music app and it only happens when the phone is locked (no pin or anything just screen off).
    I drove about an hour with the Maps app open for navigation and music playing in the background and it didn't pause at all or once at max (don't remember exactly however it would've paused a few dozen times if the screen was off).
    Wednesday, May 25, 2016 9:47 AM
  • Looks like I was 100% correct. The new system does NOT guarantee you the resources. As soon as the app is closed, background audio no longer works. This is a HUGE stepback from 8.1 systems, and frankly, a huge failure, given how much it was applauded by microsoft...

    I am beginning to see why developers are avoiding the platform now...


    2 process is still the way.
    I feel so stupid for waiting RS1 like the day of salvation. Such a huge disappointment.
    • Edited by mcosmin Sunday, August 7, 2016 10:28 AM
    Sunday, August 7, 2016 10:26 AM
  • @mcosmin, if you'd like to have a constructive conversation I'd be happy to help investigate what you're seeing, but if you're just going to troll then that's not going to be a productive use of anyone's time.

    As I understand the current problem you're reporting:

    "As soon as the app is closed, background audio no longer works."

    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 appear to 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:25 PM
  • Having to deal with little to no documentation and really no platform support for years tends to do that to people. Especially when there is a stealth design breaking change like this one that is never mentioned in any of the documentation.

    Yes, I overreacted and I am sorry for that, but I've worked too much on this platform and there is always the little things that let you down when it comes to AV on Windows Phone/Mobile/whatever.


    And if you look from my side, you will see why I think this is a bug, just like the play/pause in media stream sources with buffer times bigger than 0 on WP8.1, that never got fixed in that release.
    • Edited by mcosmin Monday, August 8, 2016 7:31 AM
    Monday, August 8, 2016 7:29 AM
  • 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.

    @Aaron: On Windows Phone, closing the app via app switcher never stopped background audio from running inside the background task. And I assume that the same is true on PC if you used the background task (not 100% sure, I always used MediaElement approach on PC). So the new behavior is different than what we had before, at least on the WP platform. Closing the app was always how I tested background audio on WP.

    Actually, the old behavior was pretty confusing, and I got a bunch of customer complaints about this. It is not logical or intuitive that the app keeps playing music, even if you explicitly close it. But it was impossible to even detect that the app was closed, so users had to live with this. So while I am actually glad that the behavior has changed with  the new in-process approach, it still is a breaking change in behavior and might confuse developers and users.

    Monday, August 8, 2016 8:25 AM
  • 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.

    @Aaron: On Windows Phone, closing the app via app switcher never stopped background audio from running inside the background task. And I assume that the same is true on PC if you used the background task (not 100% sure, I always used MediaElement approach on PC). So the new behavior is different than what we had before, at least on the WP platform. Closing the app was always how I tested background audio on WP.

    Actually, the old behavior was pretty confusing, and I got a bunch of customer complaints about this. It is not logical or intuitive that the app keeps playing music, even if you explicitly close it. But it was impossible to even detect that the app was closed, so users had to live with this. So while I am actually glad that the behavior has changed with  the new in-process approach, it still is a breaking change in behavior and might confuse developers and users.

    Trust me, this is going to be even more confusing.

    Because now if you force close on windows phone, app stops music, but if the app foreground UI is reclaimed by the OS, it does not stop the music, and, of course, you will not be able to force close to stop it since it is not in the task manager anymore. So in truth, this actually doesn't really fix anything, but for users who are used to the following usage pattern (start app -> queue something -> force close foreground process) it will get even more annoying because they will blame your app for being broken, especially because most apps in the store will still be using the 2 process approach which does not have this problem.


    To fix this issue it would be nice if the OS had a "stop music" feature built in, as many players are not providing their own, or the playback app should always stay in the task manager, even if the foreground app is actually reclaimed by the OS (this would actually be pretty cool from the user perspective, since they would know which app is actually playing the music).
    • Edited by mcosmin Monday, August 8, 2016 8:35 AM
    Monday, August 8, 2016 8:31 AM
  • @Aaron: On Windows Phone, closing the app via app switcher never stopped background audio from running inside the background task.

    This is true and this behavior has not changed. The app switcher lets you close the app; it does not let you close the background task host that happens to be playing audio.

    So the new behavior is different than what we had before, at least on the WP platform.

    No, we haven't changed any behaviors. Closing a process has always stopped it from playing audio. It's just that the WP app switcher doesn't let you close the background task host in a multi-process audio model so it keeps playing.

    Closing the app was always how I tested background audio on WP.

    You don't need to do that with single process. Just go to the home screen or switch to a different app.

    Actually, the old behavior was pretty confusing, and I got a bunch of customer complaints about this. It is not logical or intuitive that the app keeps playing music, even if you explicitly close it.

    That's consistent with the feedback I've heard as well.

    So while I am actually glad that the behavior has changed with  the new in-process approach, it still is a breaking change in behavior and might confuse developers and users.


    This is not a breaking change. In fact, we've made no change at all to how processes are terminated. The difference here is that if you terminate a single process app you're of course terminating the process that was playing the audio. But that's not a platform change.
    Monday, August 8, 2016 9:10 AM
  • This is not a breaking change. In fact, we've made no change at all to how processes are terminated. The difference here is that if you terminate a single process app you're of course terminating the process that was playing the audio. But that's not a platform change.

    Technically you might be right. But from a user experience point of view, this is a breaking change. Previously, when the user closes the player in the task switcher, music keeps playing. Now if the user closes the player, music stops.

    Trust me, this is going to be even more confusing.

    Because now if you force close on windows phone, app stops music, but if the app foreground UI is reclaimed by the OS, it does not stop the music, and, of course, you will not be able to force close to stop it since it is not in the task manager anymore. So in truth, this actually doesn't really fix anything, but for users who are used to the following usage pattern (start app -> queue something -> force close foreground process) it will get even more annoying because they will blame your app for being broken, especially because most apps in the store will still be using the 2 process approach which does not have this problem.

    I do not think that there will be a problem. First, I do not believe that any user out there actually closes the app and expects the music to continue. I think the old behavior was irritating and it is good that this is fixed, so now the user experience will finally bewhat they expect. Second, even if the OS reclaims the foreground UI, the app will still be in the task manager. So you can still close it and this should terminate playback. Apps do not disappear automatically, no matter if they are suspended or even termintated. You still see the last screenshot in the task manager and when clicked on, the app will be resumed or restarted. Only if you manually close it, it will be removed from the task manager.

    Monday, August 8, 2016 11:12 AM
  • Ok, I might have been mad last night but I don't think I've gone completely insane (or maybe I might have?).

    This is very easy to reproduce with the background media playback sample from github. Open it on phone, start playback, then open 16 (or 8 if you use a 1 GB device) other apps. You will see the sample app disappears from the task switcher and it will continue to play music.

    Monday, August 8, 2016 11:29 AM
  • Oh you might be right on that. I did not consider opening so many apps. It is probably not such a common scenario but I agree that it would be a lot better if the system would keep the app in the task switcher, as long as it is playing background music.
    Monday, August 8, 2016 12:29 PM
  • I think it has to do with RAM consumption rather than actual app numbers but I  don't have any memory hog app to test against.
    Monday, August 8, 2016 12:34 PM
  • No, if an app gets deleted from RAM, it will still be visible in the task switcher. When you switch back to an app and see that well known "Loading..." screen, then this app has been deleted from RAM and is now being restarted. This happens quite frequently when switching between multiple apps, unless your phone has a lot of RAM.
    Monday, August 8, 2016 1:19 PM
  • Either way, the app still disappears when you open too many apps, and that by itself can be confusing, especially since the cap seems to be dependent on the phone (on L830 i can open just 8).

    Monday, August 8, 2016 1:52 PM