[alsa-devel] ALSA default buffer sizes
manuel.jander at gmail.com
Mon Aug 24 20:38:15 CEST 2009
>> The question is, who is the entity deciding those default values ?
> snd_pcm_hw_params_choose() in alsa-lib/src/pcm/pcm_params.c:
> /* Choose one configuration from configuration space defined by PARAMS
> The configuration chosen is that obtained fixing in this order:
> first access
> first format
> first subformat
> min channels
> min rate
> min period time
> max buffer size
> min tick time
Thanks, that information is really helpful. But why would it be a good
idea to pick to lowest period time ?
Maybe a given soundcard is able to do 4 byte periods and all those low
delay freaks will just start drooling
because of that fact, but obviously with a high interrupt trigger
rate, thus consuming more CPU. But OK,
if you want low delay, you gotta pay for that.
The fact that a soundcard is capable of doing that extreme low delay
setting, does not necessarily mean
that I want to favor that. Keep it mind that not every machine is a
x86 with 3GHz.
Can anyone tell me why choosing the smallest period size by default is
a good idea ?
Maybe it would be good to know inside the driver that the user program
does not actually care about the
The problem is, as far as I understand right now, I would have to
increase the minimum period time of the
au88x0 driver, to get a reasonable setting for audacious, but that
would limit the low delay capabilities for other
applications that might do somewhat smarter buffer settings.
As a work around, maybe I could set the minimum period bytes to 0, and
if I encounter that value
at snd_pcm_xxx_hw_params(), override that value with something useable
and reasonable ? For an mp3
player, period sizes below 576 audio samples would not make any sense
either, so I would prefer 1024
frames rather than 1.
> au88x0_pcm.c has period_bytes_min = 0x1 and periods_max = 32.
> Is that periods_max an actual hardware limit?
No. I considered that anything beyond 32 is just plain stupid :) The
case for period_bytes_min = 0x1 is only
valid for 8 bits mono audio of course. I think that needs to be changed.
More information about the Alsa-devel