[Openal-devel] alcSuspendContext()

[Xavier Bouchoux]

Martijn Buijs a écrit :
> 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 (I hope! since that's what I'm using...) that using listener 
relative sources with a non-moving listener avoids this issue.

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

I do call alcProcessContext() every frame, when I'm done updating 
everything.
but I think all implementations are ignoring it. It's just that 
apparently if I read the doc correctly, an implementation could be in 
the ALC_SYNC mode true, and the call would then be mandatory.

Maybe the call could be use as a hint by the implementation?
if it's called the the implementation knows the state is fine. And if 
after some timeout it hasn't been called then it just goes on..
not very elegant or robust, but hey...