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. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
