« Return to Thread: Maximum Auxiliary Effect Slots

Re: ALC_EXT_STATIC_BUFFER

by Bob Aron :: Rate this Message:

On Jul 9, 2009, at 12:57 PM, Chris Robinson wrote:

> 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.

With alBufferData() this is true, because the implementation has
copied the data into it's own buffers.
With alBufferDataStatic(), it is not true because the implementation
may be referencing the data buffer provided by the client.
Before the client can delete the data buffer provided to
alBufferDataStatic() , a successful (as in alGetError() returns no
error) call to alDeleteBuffers(), alBufferData(), or alBufferDataStatic
() must be made. This lets the client know the implementation is not
using the data because it allowed the OpenAL Buffer to be deleted or
modified.

> 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.

In all the cases where the OpenAL implementation owns the resources
(source, buffer, etc objects) this is true, because the implementation
can decide when to dispose the objects.
Because the application owns the data buffer provided to
alBufferDataStatic() this is not true. The 'reasonable' way for the
app is to check the error after calling alDeleteBuffers(), alBufferData
(), or alBufferDataStatic() on a OpenAL Buffer that has been provided
a static buffer.

-bob

> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

« Return to Thread: Maximum Auxiliary Effect Slots