[Openal-devel] alcSuspendContext()

[Chris Robinson]

On Monday 18 February 2008 03:52:01 am Richard Furse wrote:
> Okay. Batching-up of state changes seems sensible/necessary to me in the
> asynchronous scenario, in the same way that transactions provide
> consistency in SQL databases. If a source is initially at <0,0,0> and a
> listener at <10,0,0>, and the source is moved to <9,0,0> and the
> listener to <19,0,0> in one "batch", then I'd expect OpenAL not to
> glitch. Without suspension, there's a risk that a block of audio is
> rendered half way through the state changes, i.e. with the source at
> <9,0,0> and listener at <10,0,0> - which would be bad.

I think the audio changes would be fast enough that it would be rather 
imperceivable. Generally you update things independant of each other anyway, 
so if you move the source, it was because the source moved, and if you moved 
the listener, it was because the listener moved. I don't think positions 
would make large jumps like that in normal situations, so between the 
gradualness of changes, and the logical independance of the two "objects", 
having a buffer update in between a batch of changes isn't going to be badly 
perceived by a user.

Having said that, batching updates is useful for hardware, so they could take 
a bunch of changes, and update the card parameters at once, instead of at 
each call, such as in your example: the source changes position causing the 
card to change its playback, then the listener position changes which causes 
all non-local sources to change. In OpenGL, this is done by having commands 
buffered, that are then sent to the card whenever the driver deems 
appropriate (eg. after a certain amount of calls, or when glFlush/glFinish is 
called (which is implicitly done by SwapBuffers), or even immediately if 
appropriate).

AL, however, doesn't have any Flush or SwapBuffers-like command. Perhaps this 
can be added as an extension, to be promoted to core on the next AL core 
update? Add alFlush and alFinish commands, and something like an ALC_BUFFERED 
context attribute to hint that buffering commands is allowed by the app 
(otherwise unexpecting apps would fail to flush buffers).

But IMO, batching shouldn't be strictly enforced by the API spec. It would add 
unnecessary complexity to software mixers because they'd have to either 
shadow almost all state parameters (resource consuming) or block the mixing 
thread to make sure changes aren't used yet (potentially causing skipped 
updates; much worse than a seemingly single movement being done it two 
elongated steps).