Can anyone help with a potential memory leak I’m seeing with Monogame’s MediaPlayer? The following test code increases my game’s memory usage by approx 1Mb every time the while loop executes. If I pause the loop, memory usage remains static, until I resume and the memory starts going up again. Is there something I should be doing when changing songs? The song load is executed once, outside of the loop.
I’m using Monogame 3.7, targetting DirectX. This problem occurs on Windows 10 and Windows 11.
Song song1 = Content.Load<Song>("Music/Song1");
Song song2 = Content.Load<Song>("Music/Song2");
// Pause for a few seconds
// Pause for a few seconds
You could try my custom build where I had a complete rewrite of the audio engine and fixed a couple of issues, including management of native resources.
You can install the ‘MonoGameSetup 3.8.9010.exe’ (or newer) from here, which would replace your current MG3.7 version but works more or less the same.
Or if you don’t want to replace the entire SDK, you could remove the reference to monogame in your project and replace it with the nuget at NuGet Gallery | MonoGame.Framework.WindowsDX.9000 3.8.9010
Thanks for the info @nkast. I’m literally days away from releasing a project that’s been over 3 years in the making, so I want to avoid upgrading to Monogame 3.8 if possible. This was a bug that one of the testers discovered at the 11th hour, so to speak. If it’s a bug in the framework, then I was hoping to find some kind of workaround, but the MediaPlayer object is so simple to use that I don’t see any methods or properties that are going to help me out.
This morning I’ve tested the above scenario in Monogame 3.8 and the same thing occurs. Every time MediaPlayer.Play is called, a little bit more memory is consumed. The memory is never freed up. Again, if I pause the loop, memory usage stays static until I resume.
What I’m doing with the example is speeding up reproduction of the problem, but it does represent how I deal with music when moving from the menu screen to the actual game, and then back to the menu screen, etc, etc.
Surprised this hasn’t come up before, which leads me to believe I’m doing something wrong.
you 've build a sample?
Can you possibly put it up on github or share the zip file on onedrive/googledrive?
Yeh sure, I’ll sort that out tomorrow and upload it.
I wanted to warn you that doing garbage collections tests in a “closed loop” with MonoGame sometimes lead to false leaks.
There was a leak report a long time ago very similar to this: https://github.com/MonoGame/MonoGame/issues/6861
In this false bug report, GraphicsDevice holds a list of its resources, and they’re effectively freed when you exit the Draw function despite doing a Dispose. If you do a loop which never leaves Update or Draw, MG doesn’t have the chance to really free the memory.
I’m not saying there’s no leak, just that the test, if it’s inside a while (true) and never leaving, may give innacurate results.
That’s interesting, thanks @KakCAT. The example above is the bare bones of it, just to illustrate the problem, it’s not my actual code. My full game code leaks memory, unless I turn off the music. So I wrote a test application that switches between songs at regular intervals to isolate the issue. It has controls to stop and start the loop to give the application a breather, and it does explicit garbage collection. Neither help, the issue still persists. I’ll post an example later today.
Here’s a link to the Visual Studio 2019 test project, which targets Monogame 3.8
Instructions are on screen when the application running.
I run your sample under the VS19 memory profiler and I can confirm that the memory increases by 1M on every stop / play. I 'll look at it in more details over the weekend.
Thanks, be interesting to see what you find.
Here is an updated project. I am not sure If i have eliminated all the leaks yet but it’s somewhat improved.
Hi @nkast, thanks for the update. Yes, that appears to work! What was the problem? I see you’ve updated your MonoGame.Framework.WindowsDX.9000 package.
It was a SharpDX object, MediaEvent, that required manual disposal.
Ahhh cool, thanks so much for looking into it, appreciate your help.
So what’s the deal with the MonoGame.Framework.WindowsDX.9000 package? Is it a stable version? My game is only a week or so from release so I’m a bit nervous about changing the Monogame framework version, but happy to give it a good testing if you can give me an indication of how stable you think this version is?
I am trying to keep it production ready and not introduce new bugs.
However it’s possible that it wont work out of the box.
I have removed some of monogame’s extensions,
and it might throw exceptions in places that
i think it should or where the original XNA did.
For example if your resources exceed the Graphics profile limits
(texture sizes, unsupported states, texture formats, etc), you would
have chose a higher GraphicsProfile.
You can find all the changes here on my github.
Ok cool, thanks for the info. I’ll create a copy of the project and try it out.
Thanks again for helping out.