[Openal] OpenAL backend buffer size
chris.kcat at gmail.com
Wed Jun 13 19:49:10 PDT 2012
On Thursday, May 31, 2012 12:41:50 PM David Hilbert wrote:
> When using alGenBuffers, it is as far as I understand not required to set
> buffer size manually. That would mean there is some default size. How is
> that size determined? How is the genbuffers (software) buffer size related
> to the backend hardware buffer size?
The buffers created by alGenBuffers have an initial size of 0 and isn't
changed until you call alBufferData, when it allocates space based on the size
of the provided buffer (which could be a bit more if there's any conversion
going on, e.g. decompressing IMA4 to 16-bit internally).
The size of the buffers that you create using alBufferData is not related to
the backend device buffer. The two are completely disconnected.
> I use alsa as backend, and when testing sound with e.g.
> aplay -D plughw:0 -vv
> I can choose hardware buffer size by passing the --buffer-size flag. My RME
> HDSP 9652 card seems to have a max buffer size of 8192, while my old Echo
> Layla 20 has 32768. How is the backend hardware buffer size determined?
> Does AL request a certain size? What happens if it is not supported by the
By default, OpenAL Soft will request a 4096-sample buffer size, with 4
periods, at 44.1khz (so there's 4 periods of about 23ms each). The ALSA
backend, however, allows ALSA to change the buffer and period sizes as needed
and will accept just about anything that's given back (so if the default
request is too much it will happily set it lower, barring any ALSA bugs).
The only real requirement is that there's at least two periods.
You can request a different buffer and period size by setting the 'periods'
and 'period_size' config options, described here:
> How is the same thing handled on windows machines?
On Windows, OpenAL Soft pretty much works the same way. It uses the backend to
request buffer and period sizes, then uses whatever it gets back. The buffers
created with alGenBuffers aren't related to the backend's buffer, except as
 There is sort of a connection with streaming sources and the period size,
since the mixer updates in period-sized chunks. Buffers can be any size, but
if you want a seemless playback stream you need at least two buffers in a
source queue that together fill at least two device periods. The approximate
period size can be gotten using the device's ALC_REFRESH attribute:
/* After creating a context... */
alcGetIntegerv(Device, ALC_REFRESH, 1, &refresh);
period_size_in_millisec = 1000 / refresh;
The period size is typically pretty small (about 20~25ms), so unless you're
trying really hard to play a low-latency interactive stream, it's not
something you need to worry about it.
 Unfortunately there seems to be some bugs with ALSA changing the requested
buffer size, on some hardware:
There's not much OpenAL Soft can do about this, though.
More information about the Openal