« Return to Thread: Maximum Auxiliary Effect Slots

RE: ALC_EXT_STATIC_BUFFER

by Richard Furse-2 :: Rate this Message:

Yep. This is what we do for alBufferData() - the issue is
alBufferDataStatic() - I was worrying about the guarantees expected here.
With alBufferData() the driver manages memory and so can do the cleanup at
the right time.

Of course, the same guarantee COULD be provided here too - but this
introduces an extra thread contention between the rendering thread and the
game thread which I'm trying to avoid. I'm trying to keep possible blocking
on the game thread (a) minimal and (b) predictable and handling
alBufferDataStatic() "synchronously" messes with that. I'm supporting
process/suspend properly too which makes this even more horrid...

(I'm actually still very unconvinced that alBufferDataStatic() is a good
idea at all, but people seem to want it so I'm checking it out...)

--Richard

> -----Original Message-----
> From: openal-devel-bounces@...
> [mailto:openal-devel-bounces@...] On
> Behalf Of Chris Robinson
> Sent: 09 July 2009 20:57
> To: openal-devel@...
> Subject: Re: [Openal-devel] ALC_EXT_STATIC_BUFFER
>
> 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
>

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

« Return to Thread: Maximum Auxiliary Effect Slots