AudioBuffer failing to release

#1 Really weird. I don't have any idea what is going on, but what do your audio datablocks look like?

#2 Thanks Kevin. Here is a series of snippets from my gameScripts/datablock.cs file:

new AudioDescription(AudioOnce)
{
volume = 1.0;
isLooping= false;
is3D = false;
type = 0;
};

...

$Yep::AudioPreload = true;

...

new AudioProfile(axeEnterAudio)
{
filename = "game/data/audio/axe_swish_1_008713052-axe.ogg";
description = "AudioOnce";
preload = $Yep::AudioPreload;
};

It doesn't vary much from that. For my AudioDescriptions (there are 3), I always use type=0. That's the strangest parameter. For AudioProfiles, I have many that are almost identical to this one.

#3 Hmm, I have no idea what type really is either, but for my datablocks, I have a different int for type for each AudioDescription.

It doesn't seem like this would be your problem, but it's a quick fix and easy test.

new AudioDescription(MusicLooping)
{
    volume = 1;
    isLooping= true;
    is3D = false;
    type = 0;
};

new AudioDescription(SoundEffectLooping)
{
    volume = 1;
    isLooping= true;
    is3D = true;
    type = 1;
};

new AudioDescription(MusicNonLooping)
{
    volume = 1;
    isLooping= false;
    is3D = false;
    type = 2;
};

#4 Alas, changing "type" did not help. A couple of months back I perused the AL code to see what it was. Sadly, I do not remember, but I believe it was an organizational type thing that didn't really matter what I set it to.

Well thanks anyway. I'm probably not going to dig for this just yet, but I'll try to post any answer I find when the time comes.

#5 I've never had a buffer problem, have you tried adding this to your endGame() scripts?

alxStopAll();

It might not "fix" the problem, but should kill anything that might be persistently playing.

#6 In audio/audioBuffer.cc:

AudioBuffer::~AudioBuffer()
{
   if( malBuffer != 0 ) 
   {
     alGetError();
     alDeleteBuffers( 1, &malBuffer );
     ALenum error = alGetError();
     AssertWarn( error == AL_NO_ERROR, "AudioBuffer::~AudioBuffer() - failed to release buffer" );
   }
}

If you check that error code it turns out that the call to alDeleteBuffers() is trying to delete an invalid buffer. The buffer appears to have been released before this destructor is called, and we're getting an error trying to delete it again. I have not done any profiling to ensure that the memory has been properly released but I have been wrestling with the audio system for the last two weeks and I didn't have any noticeable increase in memory consumption during development/testing.

#7 I just changed that to :

AudioBuffer::~AudioBuffer()
{
	if( alIsBuffer(malBuffer) ) 
	{
		alGetError();
		alDeleteBuffers( 1, &malBuffer );

		ALenum error;
		error = alGetError();
		AssertWarn( error == AL_NO_ERROR, "AudioBuffer::~AudioBuffer() - failed to release buffer" );
		switch (error)
		{
			case AL_NO_ERROR:
				break;
			case AL_INVALID_NAME:
				Con::errorf("AudioBuffer::~AudioBuffer() - alDeleteBuffers OpenAL AL_INVALID_NAME error code returned");
				break;
			case AL_INVALID_ENUM:
				Con::errorf("AudioBuffer::~AudioBuffer() - alDeleteBuffers OpenAL AL_INVALID_ENUM error code returned");
				break;
			case AL_INVALID_VALUE:
				Con::errorf("AudioBuffer::~AudioBuffer() - alDeleteBuffers OpenAL AL_INVALID_VALUE error code returned");
				break;
			case AL_INVALID_OPERATION:
				Con::errorf("AudioBuffer::~AudioBuffer() - alDeleteBuffers OpenAL AL_INVALID_OPERATION error code returned");
				break;
			case AL_OUT_OF_MEMORY:
				Con::errorf("AudioBuffer::~AudioBuffer() - alDeleteBuffers OpenAL AL_OUT_OF_MEMORY error code returned");
				break;
			default:
				Con::errorf("AudioBuffer::~AudioBuffer() - alDeleteBuffers OpenAL has encountered a problem and won't tell us what it is. %d", error);
		};
	}
}

This eliminates the console warning and is probably more correct - the malBuffer variable technically contains a handle, not a pointer, so testing like a boolean is not really appropriate. I also added the expanded error output because I got tired of the generic "you fail" message.

#8 Awesome. What version of TGB does this problem crop up in?

#9 Got me - It's there in 1.7.6, but it probably goes further back than that.

#10 Thanks everyone. I tried the alxStopAll() as the lazy solution, but it didn't work.

I suppose the AL library has a pretty ugly bug then @Richard, and I should follow your lead and clean up the destructor routine. Ugh. :P

#11 And it might be advisable to update to the latest version of the OpenAL library. Creative has placed it in a public svn server (svn://connect.creativelabs.com/OpenAL) or there is a pre-built distribution (several really) available at http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx .

DISCLAIMER
I say "might" because I'm not sure what sort of sound issues might ensue on the cross-platform front from this. I'm only throwing it out there as an option, if anyone feels like playing guinea pig and then informing the rest of us that'd be swell!

I have tried it under Win7 and it works quite well.