Audio problems..

#1 Tracking things down further...
I'm trigerring another error after an alxStop call in PlayGui::onWake

I stop my main music sound here and I end up getting error a004 from openAL:

/**
 * A function was called at inappropriate time,
 *  or in an inappropriate way, causing an illegal state.
 * This can be an incompatible ALenum, object ID,
 *  and/or function.
 */
#define AL_INVALID_OPERATION                     0xA004

I also notice that this seemed to happen a couple times on shutdown comming from alxStopAll I think.


I verified that the error is in alxStop by checking for al errors at the beginning of the function and at the end of the function. and only the check at the end of the function fires off.


some help please?

#2 Tracking it down further .... the AL_INVALID_OPERATION is comming from:

VorbisStreamSource::freeStream

from the call:

alDeleteBuffers(NUMBUFFERS, mBufferList);


I checked that the requested buffers are generated without an error and it looks like they are..further I go deeper into the caverrns of TGE audio....

#3 Ok, tracked one of the problems down...the source is still playing when the buffers are attempted to be deleted.

Here is my version of freeStream that I'm using that fixes this for the vorbisStream problem

the main change is to stop the source, find out how many buffers are queued, and unque them then do the delete as before.

this succeeds and leaves the device in a valid state. (hopefully!)

void VorbisStreamSource::freeStream() {
	bReady = false;

	alGetError(); //clear error state so we can check it here.

	if(stream != NULL)
		ResourceManager->closeStream(stream);
	stream = NULL;

	
	alSourceStop(mSource);
	ALint error = alGetError();
	if(error != AL_NO_ERROR)
	{
		Con::errorf("audio: VorbisStreamSource::freeStream  alGetError()#0  reported an error: 0x%x", error);
	}

	if(bBuffersAllocated) {
		if(mBufferList[0] != 0)
		{
			if(!alIsBuffer( mBufferList[0]))
			{
				Con::errorf("audio: VorbisStreamSource::freeStream  !alIsBuffer( mBufferList[0]) ");
			}
			int numQueued = 0;
			alGetSourcei(mSource, AL_BUFFERS_QUEUED, &numQueued);
			error = alGetError();
			if(error != AL_NO_ERROR)
			{
				Con::errorf("audio: VorbisStreamSource::freeStream  alGetError()#1  reported an error: 0x%x", error);
			}

			ALuint bufferID;
			for(int b = 0 ; b < numQueued ; ++b)
			{

				alSourceUnqueueBuffers(mSource, 1, &bufferID);
				error = alGetError();
				if(error != AL_NO_ERROR)
				{
					Con::errorf("audio: VorbisStreamSource::freeStream  alGetError()#2  reported an error: 0x%x", error);
				}
			}
			error = alGetError();
			if(error != AL_NO_ERROR)
			{
				Con::errorf("audio: VorbisStreamSource::freeStream  alGetError()#3  reported an error: 0x%x", error);
			}

			alDeleteBuffers(NUMBUFFERS, mBufferList);
			error = alGetError();
			if(error != AL_NO_ERROR)
			{
				Con::errorf("audio: VorbisStreamSource::freeStream  alGetError()#4  reported an error: 0x%x", error);
			}
		}
		for(int i = 0; i < NUMBUFFERS; i++)
			mBufferList[i] = 0;

		bBuffersAllocated = false;
	}

	if(bVorbisFileInitialized) {
		vf.ov_clear();
		bVorbisFileInitialized = false;
	}
}

#4 Ok and here is the problem with the alEnable(AL_DISTANCE_MODEL);

from openal docs..

Quote:
alEnable
Description:
This function enables a feature of the OpenAL driver.
C Specification:
ALvoid alEnable(ALenum capability);
Parameters:
capability The name of a capability to enable
Return Value:
None
Remarks:
At the time of this writing, there are no features to be disabled using this function, so if it is called the error
AL_INVALID_ENUM will be generated.

so getting rid of that call to enable the distance model should do the trick. unless there's something I don't know.....and there are oh so many things that I don't!
-c

#5 For the second init problem: alListenerf(AL_GAIN_LINEAR, 1.f);
I think that this is just a mistake by someone and should be AL_GAIN instead of AL_GAIN_LINEAR

AL_GAIN_LINEAR reports invalid enum for this call to alListenerf

#6 Unrelated to my current problem (I think) but..
just noticed this comment :

audioDataBlock.cc

// Doh!  Something missing from the unpackData...don't want to break
   // network protocol, so set it to true always here.  This is good for
   // ThinkTanks only.  In the future, simply send the preload bit.
   mPreload = true;

not sure what to make of it if it should be that way or is a problem.

#7 Oh yesss....very close to finding my problem now...after a day and a half of adding some error reporting...I've found that when my footstep sounds are playing correctly I get one log trace and when they are mixed up and playing incorrectly I get a different log trace...

when they fail this message executes in AudioDataBlock.cc

ALuint bufferId = mBuffer->getALBuffer();
		 if(bufferId == 0)
		 {
			Con::errorf("audio: AudioProfile::onAdd  mBuffer->getALBuffer returned a null buffer id");
		 }

so it seems that sometimes I'm getting a null buffer. and sometimes not.
back into the cavern of audio I go anyone else want to tag along? grab a torch and come this way....but beware madness lies this way...madness....

#8 Are you messing around with the new openAl.dll or SDK ?
Dont dig to deep Clint take a look at this resource instead
NewAudio

#9 I'm messing arround with the 1.3 stuff from cvs....
I've finally tracked it down about as deep as it can be tracked to this

on some runs it looks like the ogg files aren't being sucessfully opened.
in OggVorbisFile::_get_prev_page

/* we have the offset.  Actually snork and hold the page now */
  _seek_helper(offset);
  ret=_get_next_page(og,CHUNKSIZE);
  if(ret<0)
  {
	  //Clint: if it's not possible then we should assert!!%$#%$%#%
	  Con::errorf("OggVorbisFile::_get_prev_page apparently the impossible is possible!");
    /* this shouldn't be possible */
    return(OV_EFAULT);
  }

the impossible is possible...unfortunately for me :)

Quote:
Dont dig to deep Clint take a look at this resource instead
NewAudio

you know what....thanks for reminding me about that resource...I had looked at it before and saw the initial replies that made it sound like there were some bugs in it....but obviously I'm not safe from bugs with 1.3's audio either : (

I'll look at it more closely..if the ogg streaming stuff is cleaned up I'll definitely be interested.

#10 I'm going to track this down a bit further in case it's not caused by something that is fixed in that resource...

so far it looks like the stream and the resource object we are attempting to open are good..

#11 Ok I'm done for now, I'll try the new audio resource tomorrow and see how that goes

#12 So far those fixes you have here are real good ones .
I still use SDK 1.3 Audio , i tried the newAudio resource but hade some problems with wave files.
I mailed Marcelo about it and he gonna fix that later.
So if you still going to dig in this , if you have time check why the new openal.dll not working.

Great work othervise !!

#13

Quote:
I still use SDK 1.3 Audio...... i tried the newAudio resource but hade some problems with wave files.

heeeeeeyyy didn't you just suggest I try the new resource instead of this one :)

maybe some G.G. angel with swoop in and save us hint hint hint

#14 Hey Clint

I updated my audio a while back and implimented the EAX support. So far everything seems to work correctly for me. I played around with the update that Billy refered to. Marcelo cleaned everything up very well and fixed allot of problems but it lacked some of the features I needed. I'll grab a torch and tag along with you and see what else can be found....:-)

#15 Hehe I only suggested this because you are a good coder and i think this NewAudio probably going to show up in SDK 1.4.
I think Ben know more about this .

#16 @Jackie, did you work on the ogg vorbis stuff at all? If so I'd be interested in seeing what you have.

I looked at Marcelo's stuff more last night (very early this morning) and it does look very nice, probably a nicer starting point to start debugging.

I'd love to know what GarageGames' plan is for the audio stuff, if they are going to switch over to something based on Marcelo's re-organization then I should definitely be working with that and taking care of any bugs we find there.

#17 Here's some more info that might set some alarms off for somebody...

So the problem for me is difficult to reproduce..once it starts happening it seems to happen all the time, sometimes a reboot makes it go away, sometimes a reboot doesn't help.

Last night I was lucky because I could reproduce it consistently for about 6 hours...but then this morning I get up and can't reproduce it anymore.

Last night If I ran from inside of MSDev the problem would not happen. If I ran from a shortcut I had in my start menu it would happen every single time.

I double checked that the working directory was the same, and I could tell I was running the same exe since the changes I made in msdev showed up when I used the shortcut (but I double checked anyway)

Whenever I've ran into problems like this before, it has usually been related to a change in the timing of execution and the order things are run in. I'm not sure if that's the problem here or not but something to think about.

Also in case it's not clear, the way the problem manifests itself for me is that all of a sudden on one run, certain sound files play a different audio file...when walking yuo will hear the crossbow explosion sound or maybe when shooting the crossbow you will hear the explosion sound instead of the firing sound.. things like that.

I'll see if I can make it start happening again today.

#18 Here's another interesting thing, in AudioDataBlock.cc

bool AudioProfile::onAdd()
{
   if (!Parent::onAdd())
   {
	  Con::errorf("audio: AudioProfile::onAdd returned false" );	  
      return false;
   }

   // if this is client side, make sure that description is as well
   if(mDescriptionObject)
   {  // client side dataBlock id's are not in the dataBlock id range
      if (getId() >= DataBlockObjectIdFirst && getId() <= DataBlockObjectIdLast)
      {
         SimObjectId pid = mDescriptionObject->getId();
         if (pid < DataBlockObjectIdFirst || pid > DataBlockObjectIdLast)
         {
            Con::errorf(ConsoleLogEntry::General,"AudioProfile: data dataBlock not networkable (use datablock to create).");
            return false;
         }
      }
	  else
	  {
		  //CLINT: this just means it's client side I think
		  //   from the above comment
	  	 // Con::errorf("audio: AudioProfile::onAdd bad datablock id?" );	  
	  }
   }
   else
   {
	   Con::errorf("audio: AudioProfile::onAdd no AudioDescription object" );	  
   }

   if(mPreload && mFilename != NULL && alcGetCurrentContext())
   {
      mBuffer = AudioBuffer::find(mFilename);
      if(bool(mBuffer))
      {
         ALuint bufferId = mBuffer->getALBuffer();
		 if(bufferId == 0)
		 {
			Con::errorf("audio: AudioProfile::onAdd  mBuffer->getALBuffer returned a null buffer id");
		 }
      }
	  else
	  {
		  Con::errorf("audio: AudioProfile::onAdd  did not find mBuffer: %s", mFilename );
	  }
   }
   else
   {
	   //report errors for anything other than !mPreload
	   if(mFilename == NULL)
		   Con::errorf("audio: AudioProfile::onAdd  mFilename == NULL");
	   else if(!alcGetCurrentContext())
		   Con::errorf("audio: AudioProfile::onAdd !alcGetCurrentContext()");

   }

   return(true);
}

I added checks for all the alternate cases and found that a couple of them were getting hit, but not changing the return value. in particular this one:
"Con::errorf("audio: AudioProfile::onAdd did not find mBuffer: %s", mFilename );"

I'm not sure what sort of effect this will have if any, but shouldn't that be returning false there? as it is now it looks like it just drops down and returns true

maybe if that happens it just assumes that it's client side and that it exists there or something?

here's a section of my log file showing the output

Quote:
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav
audio: AudioProfile::onAdd did not find mBuffer: UEG_thetower/data/sound/replaceme.wav

I think we can see the culprit, but is this ok, or is this horribly horribly wrong....you be the judge! ....then tell me.

Still no luck reproducing my audio problem this morning though. oh well on to other things until it shows up. I put some more error output in the ogg function that was failing so hopefully when it happens again that will tell me more.

#19 @Clint -

It's cool that you are tracking this down. Nice to see all those error cases getting caught. But I'm confused about one thing: what is the "audio problem" you are having trouble re-producing? I couldn't find any mention of it in the thread at all.

Regarding the "did not find mBuffer" error above, isn't it just the case that the file is missing? If not, can you trace into "AudioBuffer::find" to find out why it isn't finding the file?

Again, glad to see the contributions you are making.

#20 @Clark,
thanks for the reply, I just realized I hadn't really stated the original problem before too, just did a couple posts above though :)

Quote:
Also in case it's not clear, the way the problem manifests itself for me is that all of a sudden on one run, certain sound files play a different audio file...when walking yuo will hear the crossbow explosion sound or maybe when shooting the crossbow you will hear the explosion sound instead of the firing sound.. things like that.

Quote:
Regarding the "did not find mBuffer" error above, isn't it just the case that the file is missing? If not, can you trace into "AudioBuffer::find" to find out why it isn't finding the file?

you are very correct, it's just a missing file, my question there is whether or not it should be returning false when that case occurs instead of true...my instinct is yes, but I haven't traced down how that return is used or what it means in the bigger picture of simobject management