Post by David HilbertWhen 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?
Hi.
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[1].
Post by David HilbertI 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
hardware?
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[2]).
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:
http://repo.or.cz/w/openal-soft.git/blob/6b154025ab9:/alsoftrc.sample#l79
Post by David HilbertHow 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
noted[1].
[1] 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... */
ALCint refresh;
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.
[2] Unfortunately there seems to be some bugs with ALSA changing the requested
buffer size, on some hardware:
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-March/037624.html
There's not much OpenAL Soft can do about this, though.