sharpdx / SharpDX

SharpDX GitHub Repository
http://sharpdx.org
MIT License
1.68k stars 641 forks source link

XAPO/SourceVoice not released for GC causing memory leak #494

Open JParies opened 9 years ago

JParies commented 9 years ago

It's possible I'm incorrectly characterizing the issue, but when using XAPO effects, a memory leak occurs as the effects/SourceVoices do not appear to be getting released for GC when DestroyVoice() is called on the SourceVoice.

I've uploaded a simple app that demonstrates the issue by playing a sound repeatedly with a XAPO applied. If you watch memory when the app is running, it will slowly climb. I'm working on an app that would be using multiple effects fired at frequent intervals, which would cause the issue to compound more quickly. https://onedrive.live.com/redir?resid=8C9AAADA86C94F86!1737&authkey=!AADqotfOeYjC3cw&ithint=file%2czip

Not clear to me if it's relevant, but there is a Release() method in C++ (ref: http://msdn.microsoft.com/en-us/library/windows/desktop/ee415723%28v=vs.85%29.aspx): Release the effect with IUnknown::Release. When you create an XAPO, it will have a reference count of 1. When the XAPO is passed to XAudio2 with SetEffectChain, XAudio2 increments the reference count on the XAPO. Releasing the client's reference to the XAPO allows XAudio2 to take ownership of the XAPO. If XAudio2 has the only reference to the XAPO, this reference is disposed of when it is no longer being used by XAudio2. If the client code needs to maintain a reference to the XAPO—for example, for reuse later—you can skip this step.

In running dotMemory and comparing snapshots, I'm seeing VoiceShadow and ShadowContainers that are dominators for the effects.

xapo_dominators

Hopefully this is enough information - let me know if there is anything else I can provide.

ArtiomCiumac commented 9 years ago

I've tried to run your sample - and it indeed shows that there is some memory leak, however I didn't fully understood how your sample disposes the source voices and whether it is correct or not. Therefore I am not sure if the actual memory leak is related to SharpDX itself.

Please have a look at the Toolkit.Audio implementation - it uses a source voice pool and doesn't seem to have any leaks. Feel free to adapt and reuse it to your case.

I will try to investigate it more once I will have some time.