Windows 8.1中的媒体管道坏了吗？

Question

Windows 8.1中的媒体管道似乎因内存管理问题而中断。

当您创建一个使用IMediaSource在WindowsPhoneRuntime8.1中传输音频的后台音频应用程序时，该应用程序的组件最终会在某些情况下抛出OutOfMemoryException甚至StackOverflowException。当查看内存转储时，里面有很多未收集的垃圾。

关于MSDN论坛的讨论已经开始，并取得了这样的结论。为了让Windows团队注意到这一点，我创建了一个WPDev UserVoice建议，但我仍然希望是我(以及来自MSDN论坛的其他人)错了，并且有了解决这个问题的办法。

我也有一个小的CodePlex项目，它也有这个问题，而且实际上有一个关于这个问题的发行报告。

我希望在社区的帮助下，这个问题能够被解决，或者直接传递给微软开发团队去调查和消除。谢谢!

更新1:

有一个StackOverflowException的一种解决办法，但它无助于对抗OutOfMemoryException。

Answer 1

好的，看起来问题实际上是在.NET中字节数组的生存期。

为了解决内存问题，人们应该使用Windows的Windows.Storage.Streams.IBuffer。不要以任何形式创建许多新的.NET字节数组，既不使用简单的new byte[]，也不使用System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeBuffer类，因为它是IBuffer接口的托管实现。

这些字节数组一旦被分配，就会因为被OverlappedData结构固定并溢出后台音频任务的内存阈值而存活很长时间。IBuffers (真正的Windows类，如Windows.Storage.Streams.Buffer类)包含本地数组，当IBuffer的引用计数达到0(0)时，它们就会被释放，它们不依赖于GC。

我发现这个问题不仅仅是背景音频的问题。其实，我也见过很多有关类似问题的问题。解决方案是在可能的情况下使用Windows后端，因为它是非托管的，并且一旦资源没有引用就会释放出来。

感谢@Soonts为我指明了正确的方向！

Answer 2

他们在MSS管理内存的方式上有内存问题，但是在一些更新期间，他们已经悄悄地修复了它：WP7背景音频-内存泄漏？。

我不确定，但我认为问题是你的代码。您只是不应该每次请求样例时都调用var buffer = new byte[4096];。这样做可能在PC上有效，但对于嵌入式平台来说，我不认为过多地强调内存管理器是个好主意。

在我的MediaStreamSource实现中，我使用在构造MSS时分配的单个循环缓冲区，并且在回放期间无限地重用缓冲区的部分。在我的GetSampleAsync中，我构造了一个流实现类的实例，它不拥有任何内存，而是只保存对循环缓冲区一部分的引用。这样，在回放过程中只分配了几个小对象，因此音频流数据不会加载内存管理器。