[alsa-devel] Problems with safe API and snd-cs46xx
superquad.vortex2 at gmail.com
Mon Sep 7 17:07:14 CEST 2009
do you mean that the function cannot update the min and max value ?
2009/9/7 Takashi Iwai <tiwai at suse.de>
> 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.
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
More information about the Alsa-devel