From: "Daniel Glöckner" <dg@emlix.com>
To: Mark Brown <broonie@sirena.org.uk>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH v2] tlv320aic3x: disable ADC/DAC while changing clock
Date: Wed, 01 Apr 2009 18:21:19 +0200 [thread overview]
Message-ID: <49D3947F.3010805@emlix.com> (raw)
In-Reply-To: <20090401152421.GC21294@sirena.org.uk>
On 04/01/2009 05:24 PM, Mark Brown wrote:
> 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
> configuration.
It was my impression that it is up to the pcm part to install these
constraints as this is where SNDRV_PCM_INFO_JOINT_DUPLEX can be put into
the snd_pcm_hardware structure.
>>> 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.
I can't hear any artefacts with my cheap headphones.
The delayed close is audible, though.
> It'd probably also help to only do reconfiguration if actually required
> rather than always powering down the ADCs and DACs.
That's what is done in these lines at the very first in aic3x_hw_params:
+ if (aic3x->format == params_format(params) &&
+ aic3x->rate == params_rate(params))
+ return 0;
>> One could reorder aic3x_hw_params to detect the error before the
>> first registers are written..
>
> Yes.
I'll make it three patches then:
- one to remove the redundant actions on bias level off
- one to reorder hw_params
- and one to fix the bug
Daniel
--
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany
Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
emlix - your embedded linux partner
next prev parent reply other threads:[~2009-04-01 16:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-26 13:21 [patch] tlv320aic3x: disable ADC/DAC while changing clock Daniel Glöckner
2009-03-26 13:45 ` Mark Brown
2009-03-30 12:48 ` Daniel Glöckner
2009-03-30 12:51 ` Mark Brown
2009-04-01 10:56 ` [PATCH v2] " Daniel Glöckner
2009-04-01 12:10 ` Mark Brown
2009-04-01 14:06 ` Daniel Glöckner
2009-04-01 15:24 ` Mark Brown
2009-04-01 16:21 ` Daniel Glöckner [this message]
2009-04-01 16:48 ` Mark Brown
2009-04-01 17:16 ` Daniel Glöckner
2009-04-01 17:34 ` Mark Brown
2009-04-02 7:39 ` Jarkko Nikula
2009-04-02 10:34 ` Mark Brown
2009-04-02 10:45 ` Daniel Glöckner
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=49D3947F.3010805@emlix.com \
--to=dg@emlix.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@sirena.org.uk \
/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