[alsa-devel] [PATCH 2/3] ASoC: support all possible sample rates in the WM8776 driver

Mark Brown broonie at opensource.wolfsonmicro.com
Fri Sep 16 01:49:15 CEST 2011

On Thu, Sep 15, 2011 at 11:06:53PM +0000, Tabi Timur-B04825 wrote:
> Mark Brown wrote:

> > This isn't what happens at all.  The constraints set in the DAIs
> > generally just list all the sample rates the device can possibly
> > support, there's no dynamic information injected into the subsystem
> > about what's supported.  This is because in many systems the various
> > clock rates are dynamically controlled and so the clocks are adjusted to
> > reflect the sample rates the application layer wants.

> IMHO, these two sentences contradict each other.

The first one says that the rates announced by the driver are the
superset of all rates the device can ever support, the second says that
this is done because the system can change the clock rate after we're
done announcing what sample rates we support.

> > As a result we
> > never actually bother specifying the supported rates for the current
> > clock at all, we just try to make the best of what we're given when it
> > comes to configuring which is a rather different thing.

> But why would you do that?  That just creates an artificial limitation on 
> the list of supported sample rates.  If you include a set_sysclk() 
> function in the codec driver, then you should always specify 
> SNDRV_PCM_RATE_CONTINUOUS in snd_soc_dai_driver.rates.  To me, the two go 
> hand-in-hand.

Devices, especially ones with lots of digital in them, often support a
series of specific sample rates rather than a continuous range of sample
rates.  While you can of course configure them with other setups this
will run them out of spec which may cause issues from poor performance
up to serious audio issues or misdriving of outputs (eg, class D speaker
drivers or things using charge pumps).  Most of the time things will be
OK but in general it seems better to try to stay within spec.

Fairly simple devices like the WM8776 which don't contain much digital
are commonly supported over a continuous range of sample rates so
_CONTINUOUS is suitable for them.

More information about the Alsa-devel mailing list