Severe memory leak with OpenAL sound driver

OK there is definitely a memory leak with the OpenAL sound driver.

[EDIT] Test Code here: http://www.blitzbasic.com/Community/posts.php?topic=83229

I'm using OpenAL in Vista and FreeAudio in XP. I noticed that with my game on Vista the app memory consumption was going up FAST in Task Manager when I changed screens, but the GC memory level was stable. Note that the different screens play different music.


I tested the game on XP with Freeaudio and Task Manager and GC are stable. I used OpenAL on XP and Task Manager memory consumption shot up (about 4Mb every screen change due to size of music files) and GC is stable.

OK there is definitely a memory leak with the OpenAL sound driver.

I'm using OpenAL in Vista and FreeAudio in XP. I noticed that with my game on Vista the app memory consumption was going up FAST in Task Manager when I changed screens, but the GC memory level was stable. Note that the different screens play different music.


I tested the game on XP with Freeaudio and Task Manager and GC are stable. I used OpenAL on XP and Task Manager memory consumption shot up (about 4Mb every screen change due to size of music files) and GC is stable.

I found this exact same bug quite a long time ago but I can't remember with which driver it was (OpenAL or FreeAudio) anyway it got fixed at the time, or maybe I used some different code, I can't recall. I need to find it in the fixed bug bin...

What was happening back then was when you stopped a channel playing the sound was being left in memory and was causing task manager memory to shoot up but GC to remain stable. Sounds very similar.

My code for playing sounds and music is exactly the same for OpenAL and FreeAudio (no need to make it different) just the sound driver itself is different. So I don't know if the bug is in the BRL modules or OpenAL itself.

I'd love to make a test to demonstrate but today is the last day of working on my game, it goes to QA probably at about 4am! So if anyone else feels like making an app to help prove this (it's in everyone's interested to get it fixed), that would be fantastic! Thanks.

Got an example?

Sorry Brucey I made that post halfway through by mistake. You can see that today I don't have time to make an example, but thought I'd better raise the issue right away.

To confirm the fix that happened ages ago was simply that I was using PauseChannel when a sound stopped (because it prevents a click noise) instead of StopChannel. StopChannel properly frees the sound sample, whereas PauseChannel and then nulling the channel for GC to collect does not.

Anyway, that's not the issue here as both drivers use the same code which is StopChannel based...

Old Thread about the StopChannel issue: http://www.blitzmax.com/Community/posts.php?topic=65001

That would make sense, as it's possible they may not have properly implemented the Delete() to tidy up after itself...

Is there are way to test for mem leaks in OSX btw?

Fingers crossed that this is just a simple module fix that I can patch in...

freeaudioglue.cpp has this:

int BBCALL fa_StopChannel( int channel ){
	output	*out;
	if (io==0) return 0;
	out=io->getchannel(channel);
	if (out) {
		out->stop(1);
		io->freechannel(channel);
	}
	return 0;
}

But I can't find anything similar in the OpenAL code, it's completely different.

Oh yes! :-)

(... note the sound of Brucey rubbing his hands together as he gets comfortable...)

The following assumes you are using 10.5.x. (lesser versions are similar, but not so full featured)
Righty... in Finder, go to your Developer folder. (on mine, you open the main Disk, and you should see the Developer folder there).
Then into Applications.

There you will find an application called "Instruments". However these are not of the musical variety :-p
Open Instruments, and you should have a launch window which offers you tools such as Activity Monitor, File Activity, and of most interest, Object Allocations and Leaks.

Kick off Leaks, and your instrument panel should change to show two empty graphs of Leaks and Object Allocations.

Click on the Launch Executable combo, and find the app you want to execute.
You should now see the app appear in that combobox.

When you are ready, hit the red Record button.
Your app will start and all objects will be monitored.
You can use your app while this is monitoring and at any time, Pause recording, and examine the status of all live and deallocated objects.
The graph will indicate if something is leaking - if levels off after a while, all is well (obviously ;-)

I used this system to track and plug all the Mac MaxGUI leaks.
It's an excellent tool.

I'm not current with how the official audio modules work. I presume they are loading/decoding audio directly into memory and running that through whatever audio driver can play the sounds.

lol @ Brucey, sounds great but I only have OSX 10.4 on my Macbook Pro. However I need to get a PPC Mac for the office so I'll stick 10.5 on that and check it out. Many thanks for the detail. Some users have reported sound failures on the Mac so I'm keen to see if there is a mem leak on OSX (with FreeAudio) for some reason.

As for official modules yeah, they load a music ogg (may be several Mb) into RAM, and play it with the correct driver. The StopChannel should free up the sound sample, but it does NOT in OpenAL. This is a pretty major bug if you are playing big music files.

You can see it in action by downloading any of my games and running on Vista and using Task Manager. Swap between two screens with different music. The memory should stay similar (varies a little), but it goes up a lot with OpenAL.

Okay. On 10.4, go into Developer, the Applications, then Performance Tools.
There you will see "ObjectAlloc", which work much in the same way as I've described above.

Thanks for that, will test soon just to be sure FreeAudio is OK on Mac, but I guess other people would have reported problems before now if there were some. Mind you no one has reported the OpenAL one...

OK posted an example in the bugs forum: http://www.blitzbasic.com/Community/posts.php?topic=83229

It would be great if someone can verify my findings, thx! It's in all our interests to get this fixed.