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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
