4
votes

It seems that media pipeline in Windows Phone 8.1 is broken because of a lot of memory management issues.

When you create a background audio app that uses IMediaSource to stream audio in Windows Phone Runtime 8.1, the app's components eventually throw OutOfMemoryException and even StackOverflowException under some circumstances. When looking through the memory dumps, there's a lot of uncollected garbage inside.

The discussion has started on MSDN forums and progressed to this conclusion. I have created a WPDev UserVoice suggestion in order Windows Phone team could notice this, but I still hope it's me (and other guys from MSDN forums) who's wrong and there's a solution for the issue.

I also have a small CodePlex project that also suffers from this, and there's actually an issue report there regarding this exact problem.

I hope that with the help of the community this issue can be worked around or passed directly to Microsoft development team to investigate and eliminate. Thanks!

Update 1:

There's a kind of workaround for StackOverflowException, but it doesn't help against OutOfMemoryException.

2

2 Answers

2
votes

Okay, so it seems that the problem is actually with byte array's lifetime in .NET.

In order to resolve the memory problem, one shoud use Windows Runtime's Windows.Storage.Streams.IBuffer. Don't create many new .NET byte arrays in any form, neither by simple new byte[], nor by using System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeBuffer class as it is a managed implementation of IBuffer interface.

Those byte arrays, being once allocated, live long because of being pinned by OverlappedData structures and overflow the memory threshold for background audio task. IBuffers (the real Windows Runtime ones, like Windows.Storage.Streams.Buffer class) contain native arrays that are being deallocated as soon as IBuffer's reference count reaches 0 (zero), they don't rely on GC.

What I've found out is that this problem is not only background audio specific. Actually, I have seen a lot of other questions about similar problems. The solution is to use Windows Runtime backend where possible because it's unmanaged and frees resources as soon as they have zero references.

Thanks to @Soonts for pointing me in the right direction!

1
votes

They had memory issues with the way MSS manages its memory, but they have silently fixed it during some update: WP7 Background Audio - Memory Leak or Not?

I’m not sure, but I think the problem is your code. You just shouldn’t call var buffer = new byte[4096]; each time a sample is requested. Doing so may work on the PC, but for the embedded platform, I don’t think it’s a good idea to stress the memory manager that much.

In my MediaStreamSource implementation, I use a single circular buffer that is allocated when the MSS is constructed, and the portions of the buffer are infinitely reused during the playback. In my GetSampleAsync, I construct an instance of my Stream-implementing class, that doesn’t own any memory, but instead only holds a reference to a portion of that circular buffer. This way, only a few small objects are allocated/deallocated during the playback, thus the audio stream data does not load the memory manager.