On Thursday 09 July 2009 12:08:49 pm Richard Furse wrote:
> Thanks - if I'm reading you right, this means you'll often reject the
> delete of a quick stop/unqueue/delete sequence because the audio engine
> hasn't actually finished working the audio.
This shouldn't be the case, as far as my understanding of OpenAL itself. By
the time the function call returns, the call should effectively be completed
so that any subsequent calls or use of data will not interfere with on-going
operations. For instance:
ALshort *data = new ALshort[numsamples];
alBufferData(bID, format, data, numsamples*2, freq);
in this case, you can immediately do anything with the data buffer after
alBufferData returns, from modifying to deleting, and OpenAL will not care.
Similarly:
alSourceUnqueueBuffers(sID, 1, &bID);
alBufferData(bID, format, data, numsamples*2, freq);
should work, assuming there is at least one processed buffer, because the
buffer returned to you should be unqueued by the time alBufferData does
anything. There is no reasonable way for the app to know the audio engine has
completed the request, so OpenAL needs to make sure the calls stay
synchronized.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel
