[alsa-devel] [PATCH v2] tlv320aic3x: disable ADC/DAC while changing clock

Mark Brown broonie at sirena.org.uk
Wed Apr 1 17:24:22 CEST 2009

On Wed, Apr 01, 2009 at 04:06:05PM +0200, Daniel Gl?ckner wrote:
> On 04/01/2009 02:10 PM, Mark Brown wrote:

> > Hrm, does the chip support asymmetric configurations for playback and
> > capture?

> No, why do you ask?

In that case rather than using a trigger to check if the device is
running it should be possible to use constraints to prevent
reconfiguration of the device when it's not supported - this is more
friendly to apps since they know they won't be allowed to change the

> >> + * Enables or disables the left/right ADC/DAC according to new.
> >> + * Bits in new:

> > Is this really required?  I can't see it being a good idea to bounce the
> > power of the DAC or ADC while they are live since that will impact the
> > audio stream noticably.  It looks like it'd be better to do a check
> > which refuses to do the reconfiguration when it's not possible.

> Powering off is required in case the stream has been closed previously but the
m close_delayed_work has not yet been run. That was the case where I observed the
> problems this patch tries to fix.

Eew, right.  This should go in the comments.

> > It's especially suspicious since the power of the DAC and ADC is managed
> > via DAPM; the only current user should be safe since it saves then
> > restores the state but it does raise alarm bells.

> How about making it a function that always disables the four components and
> referring to snd_soc_dapm_sync to restore the state?

Hrm.  For the ADC that's probably OK but powering off the DAC does risk
being audible in the output; that does depend on the hardware, though.
It should do the right thing, I think, but checking for audio artefacts
would be advisable.

It'd probably also help to only do reconfiguration if actually required
rather than always powering down the ADCs and DACs.

> In this version of the patch I removed the line that restores the state when
> setting the sampling rate failed in-between. Is it safe to assume that DAPM will
> not enable the ADC/DAC on other occasions before a valid sampling rate has been

You should always get a chance to do a configuration before the DAC or
ADC is enabled, yes.

> configured? One could reorder aic3x_hw_params to detect the error before the
> first registers are written..


More information about the Alsa-devel mailing list