[Openal-devel] alcSuspendContext()

[Richard Furse]

In the example below there would probably be a 10x gain jump for just
one frame, which might be quite unpleasant - but yes, it's a somewhat
extreme example and in practice games programmers could code around such
issues. There are a few examples that are more tricky, such as flipping
camera angle, but I hear what you're saying. And I suppose I agree
batching could be kinda optional - for many real-world apps, the very
occasional glitch is probably tolerable in exchange for the simplified
state management.

I suppose it also depends on how games are written - does anyone know if
"real" games out there use alcSuspendContext() and expect it to work? If
it works on the Creative cards I'm guessing this might be the case...

--Richard


-----Original Message-----
From: openal-devel-bounces at opensource.creative.com
[mailto:openal-devel-bounces at opensource.creative.com] On Behalf Of Chris
Robinson
Sent: 18 February 2008 13:19
To: openal-devel at opensource.creative.com
Subject: Re: [Openal-devel] alcSuspendContext()


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).
_______________________________________________
Openal-devel mailing list
Openal-devel at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal-devel