At Mon, 7 Sep 2009 23:07:14 +0800, Raymond Yau wrote: > > do you mean that the function cannot update the min and max value ? > > snd_pcm_hw_constraint_list(runtime, 0, > SNDRV_PCM_HW_PARAM_PERIOD_BYTES, > &hw_constraints_period_sizes); This of course influences on the buffer min/max sizes. But, this has nothing to do with the order of parameter determination at snd_pcm_hw_params() call. The PCM core determines the parameters in the order of period size, then the buffer size. That is, first choose the period size to the minimum unless explicitly set, then choose the buffer size to the max unless explicitly set. Since the max number of periods is 1024 for cs46xx, it'd choose period_size = 1, then buffer_size = 1024. So, the question is what the app expects. If the app requires the smaller period size, then this set up is OK (of course, it'd be better to check the min period and fix it somehow). OTOH, if the app prefers larger buffer sizes, then it'd be better to set the buffer size as the max first before calling snd_pcm_hw_params(). Takashi > > > 2009/9/7 Takashi Iwai <tiwai@xxxxxxx> > > > 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 > > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
