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

Takashi Iwai tiwai at suse.de
Mon Sep 7 17:01:55 CEST 2009

At Mon, 07 Sep 2009 14:29:15 +0100,
Tony Vroon wrote:
> [1  <text/plain (quoted-printable)>]
> On Mon, 2009-09-07 at 14:32 +0200, Takashi Iwai wrote:
> > Hm, I don't know of "safe API"...
> It is described here:
> http://0pointer.de/blog/projects/guide-to-sound-apis.html
> Should this be incomplete or otherwise incorrect it would be useful to
> have a rebuttal.

Thanks for the pointer.

> > A small test case, preferably a short C program just to reproduce
> > the problem would be really needed in such a case.  It's very hard to
> > guess what's going on and what is actually wrong in the driver only
> > from your problem description, because of no obvious debug logs.
> If it is anything like the Aureal Vortex bug, the minimum period size
> doesn't make sense.

Yes, cs46xx also sets the minimum bytes 1, and this can be the
same problem as aureal driver.

(BTW, this isn't exactly a driver "bug" -- if this word is meaning a
 programming error.  periods_size = 1 is no invalid setup in theory.
 But, it's rarely a sane setup in reality, so it should be fixed
 to match with the real machines indeed.)

> Unlike the older the ALSA plugin, the new ALSA-NG
> plugin in Audacious opens the audio device with defaults and does not
> attempt to set period sizes.

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.


More information about the Alsa-devel mailing list