alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Tabi Timur-B04825 <B04825@freescale.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"lrg@ti.com" <lrg@ti.com>
Subject: Re: [PATCH 2/3] ASoC: support all possible sample rates in the WM8776 driver
Date: Fri, 16 Sep 2011 00:49:15 +0100	[thread overview]
Message-ID: <20110915234914.GG3218@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4E728509.9060705@freescale.com>

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.

  reply	other threads:[~2011-09-15 23:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 17:59 [PATCH 1/3] ASoC: support sample sizes properly in the WM8776 codec driver Timur Tabi
2011-09-13 17:59 ` [PATCH 2/3] ASoC: support all possible sample rates in the WM8776 driver Timur Tabi
2011-09-14 12:36   ` Liam Girdwood
2011-09-15 10:24   ` Mark Brown
2011-09-15 15:08     ` Timur Tabi
2011-09-15 22:38       ` Mark Brown
2011-09-15 23:06         ` Tabi Timur-B04825
2011-09-15 23:49           ` Mark Brown [this message]
2011-09-16 13:48             ` Timur Tabi
2011-09-17 13:04               ` Mark Brown
2011-09-13 17:59 ` [PATCH 3/3] ASoC: improve asynchronous mode support in the fsl_ssi driver Timur Tabi
2011-09-14 12:37   ` Liam Girdwood
2011-09-15 23:06   ` Mark Brown
2011-09-15 23:49   ` Mark Brown
2011-09-14 12:35 ` [PATCH 1/3] ASoC: support sample sizes properly in the WM8776 codec driver Liam Girdwood
2011-09-14 21:51   ` Timur Tabi
2011-09-15 10:26     ` Mark Brown
2011-09-15 11:28       ` Tabi Timur-B04825
2011-09-15 13:21 ` Mark Brown
2011-09-15 15:16   ` Timur Tabi
2011-09-15 23:38     ` Mark Brown
2011-09-16  9:07 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110915234914.GG3218@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=B04825@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).