[alsa-devel] ALSA default buffer sizes

[Manuel Jander]

Hi Clemens,

>> 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
period time?

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.

Best Regards,
Manuel