[Openal] buffer size

[Peter Clare]

Nic,

openal-bounces at opensource.creative.com wrote on 09/11/2006 08:48:05:
> I read that with low-latency APIs like ASIO the buffer size can be as
> small as 2ms, however with higher level APIs like OpenAL, a typical
> minimum buffer size might be closer to 10ms (which is acceptable latency
> for my application).

Unlike ASIO or Kernel Streaming, OpenAL really isn't a low latency solution
(at least on Windows platforms).  I guess it depends on your point of view,
but I still regard 10 ms as low(ish) latency.  In my view though this is
too small a buffer size for comfort on OpenAL.


> I have tried using a total buffer size of 512 samples at 48000Hz (approx
> 10ms) divided between 16 buffers, however this is running right on the

So, you are saying that each buffer is 512/16 or 32 samples?  That really
is very small!  Or do you mean that you have 16 buffers of 512 samples
each.  If the latter then that would be the basis for a reasonable and
robust streaming system.


> separate thread with only a "Sleep(1);" preventing it from running
> continuously. CPU usage is very low (less than 10%).

The Sleep(1) could be part of your problem.  I've made measurements on
actual Sleep times and I've found that on Windows XP Sleep times have a
granularity of 10 ms (rounded up) from the point at which a thread was last
scheduled.  What this means in practice is that Sleep(1), Sleep(5) and
Sleep(10) will all result in a sleep time of 10 ms.  The 10 ms granularity
appears to be measured from the time that the thread was last scheduled.
So if you have a thread that is scheduled, does some work that takes 2 ms
and then does a Sleep(1), you actually get a Sleep time of 8 ms (i.e. 10 ms
granularity - 2 ms work time).

Of course the above comments are based on limited testing on my part and
are likely to vary across processors (particularly with Hyper Threading or
dual core) and O/S platforms.  Windows Vista is known to have changes to
the process/thread scheduling so the results there could be different.

Anyway, back to your problem.  Because your buffer sizes are 10 ms and that
Sleep granularity of 10 ms, I'd suggest that for that reason alone you need
to increase your buffer sizes do something other than Sleep.


> I have tried increasing the buffer size to 4096 samples and this helps a
> lot. Moving the window becomes possible without any interruptions, but
> playback still stops if I switch to another application etc... However,
> 80ms is a huge latency and is not acceptable for my application!
>
> Please could you let me know the usual buffer sizes and latencies for
> OpenAL on Windows, and any suggestions for preventing the interruption
> which stops the playback?

It will depend on which particular OpenAL device you are using.  You may be
able to use smaller buffer sizes (but still bigger than 10 ms) on hardware
implementations such as X-Fi.  For DirectSound, Microsoft recommend a
minimum streaming buffers size of 100 ms.  Therefore for the OpenAL
implementations that are built on top of DirectSound, you're going to get
that sort of latency too.  This latency may be hidden from you (i.e. you do
not have to use buffer sizes as big as 100 ms, but OpenAL will be using
something like that internally that will contribute to overall latency).

Upshot is that you should be able to use buffer sizes of 10 ms (as long as
you have a pool of multiple buffers of this size) but overall system
latency is likely to be much higher than this for some OpenAL devices.  And
take care with Sleep() for small time intervals.

----
Peter Clare
Technical Director, Sensaura
Creative Labs
Meadlake Place, Thorpe Lea Road, Egham, Surrey, TW20 8HE, United Kingdom
Tel: +44 1784 476755
Email: pclare at sensaura.creative.com
Web: http://www.creative.com/ & http://www.sensaura.com/