On 9/7/09, Lennart Poettering mznyfn@0pointer.de wrote:
For a short while we used to call snd_pcm_hw_params_set_buffer_size_near() first, then snd_pcm_hw_params_set_periods_near() and then snd_pcm_hw_params().
This turned out to cause a couple of issues with some drivers (i think CS46xx is one of them, ice1712 another, I lack the hw in question, so i never tried to track this down further). Basically on those drivers both _set_buffer_size_near() and _set_periods_near() would fail with EINVAL for some reason and then causing snd_pcm_hw_params() to return ENOENT. Removing the two calls and calling snd_pcm_hw_params() would however work. Changing the order of the first two calls, i.e. doing first _set_periods_near() and then _set_buffer_size_near() would make both calls succeed and the snd_pcm_hw_params(), too.
I don't know if this is relevant, but in the course of tracking down the bug which led to me creating the patch for the cs46xx driver, I downloaded the latest alsa-utils to play with the aplay source. It turned out that I could comment out either the period-setting block (which called either _set_period_time_near or _set_period_size_near) *or* the buffer-setting block (which called either _set_buffer_time_near or _set_buffer_size_near) without experiencing any ill effects on sound. It was only when I commented out both blocks that I experienced issues with the sound.
This may be obvious to people here, but being new to ALSA programming (this is literally my first excursion into it), it strikes me that this could be significant. Does it help you at all?
- Sophie.