[Openal-devel] alcSuspendContext()

[Martijn Buijs]

Chris Robinson wrote:
> 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.

Actually, this explains the problem I was having with OpenAL before. In my FPS game I noticed that 
sometimes sounds that were played locally (i.e. listener position == source position) were 
sporadicly -- but definitely noticeable -- lagging behind for a fraction of a second. In my code I 
was updating the source position almost immediately after the listener position (within the same frame).

I would very much like OpenGL-like alFlush() and alFinish() functionality!

Cheers,

Martijn