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

[Lennart Poettering]

On Mon, 07.09.09 17:01, Takashi Iwai (tiwai at suse.de) wrote:

> Maybe a bit "safer" option would be to check the period min size and
> raise to a sane value as a workaround.
> 
> Or, if the period size doesn't matter much but rather the buffer size
> is more important, you can first limit the buffer size as max.  Then
> call snd_pcm_hw_params().  Without this, the PCM core determines the
> period size first, then the buffer size.

Hmm, I wonder what this means for PulseAudio. In the past we had
various problems with the functions for setting the buffer metrics and
the order in which we called them. 

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.

It would be good if the ALSA docs would actually mention in which
order those functions need to be called, if the order matters, which
it apparently does.

(Hmm, and while we are at it. Ssome other driver I don't posess,
ens1371 has some issues with the buffer size: if you ask it for 65536
bytes in the playback buffer it will only agree to 65532. If the next
time you ask for 65532 right-away it will only agree to 65528, and so on...)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4