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

Takashi Iwai tiwai at suse.de
Mon Sep 7 17:15:35 CEST 2009


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


More information about the Alsa-devel mailing list