[alsa-devel] Problems with safe API and snd-cs46xx

[Sophie Hamilton]

On 9/7/09, Lennart Poettering <mznyfn at 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.