Re: OpenAL for flight simulator

On Thursday, October 14, 2010 3:07:11 pm Ben Supnik wrote:
> If I use the minimum number of OpenAL buffers (2) and OpenAL dequeues
> the buffers infinitely fast in its infinitely fast mix function I think
> I pick up 3n ms of latency because once I write a buffer, it sits on
> OpenAL's source Q for n ms before it sits in the non-playing hardware
> buffer for n ms before it is played for n ms.
> 
> Do the two buffers include the one being played 'now' or do I actually
> need to keep 2 of 3 buffers filled?

The two buffers include the one that is being played, yes. So when a buffer 
becomes processed, openal will (ideally) be playing the second buffer. While 
it's still playing, you unqueue the first buffer, refill it, and requeue it 
before openal is done with the second buffer.

> > http://repo.or.cz/w/alure.git/blob/HEAD:/examples/alurestream.c
> > It is, of course, subject to change until a proper release is made, but I
> > don't see it changing all that much.
> 
> Ah - I see it, and if I understand, this implementation polls at a
> global interval to pick off and refill streams.  The risk there is that
> if I don't poll frequently enough, the wasted time from when I should
> have refilled to when I did refill might be too late and I'll under-run.
>   I suppose in practice the buffers have to be long enough that the
> polling interval would be a non-issue.

Right. That's the trick, to find the right buffer size so you don't underrun, 
but not introduce too much latency. It's the same whether you use alure or 
openal directly.. just that alure helps automate things so you don't have to 
maintain as much code.
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal