[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hsilvnkuf.wl%tiwai@suse.de>
Date: Mon, 21 Jul 2014 11:04:56 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Richard Fitzgerald <rf@...nsource.wolfsonmicro.com>
Cc: Mark Brown <broonie@...nel.org>, perex@...ex.cz,
lgirdwood@...il.com, patches@...nsource.wolfsonmicro.com,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: arizona: Disable AIF TX/RX before configuring it
At Mon, 21 Jul 2014 10:01:22 +0100,
Richard Fitzgerald wrote:
>
> On Thu, Jul 17, 2014 at 08:42:15PM +0100, Mark Brown wrote:
> > On Wed, Jul 16, 2014 at 01:10:39PM +0100, Richard Fitzgerald wrote:
> >
> > > If we don't disable the AIF TX/RX then we may fall into a
> > > situation where the new AIF settings are ignored by the device.
> > > For example, this problem manifests when switching between
> > > different sample rates.
> >
> > So, what this does is momentarily disable the AIF when reconfiguring.
> > That will glitch any running audio, making me wonder if the driver
> > shouldn't be returning an error or at least complaining if it has to
> > reconfigure instead. What's the use case where this might get
> > triggered?
>
> The case being fixed is like this:
>
> aplay 48kHz.wav; aplay 96kHz.wav
>
> The second open happens before pmdown_time so the AIF is still enabled.
> Writes to the AIF config registers only take effect if the AIF is disabled.
> Without this patch, the 96kHz.wav will play at 48kHz
If the glitch really matters, the driver can minimize by checking the
change of sample rate and doing temporary turn on/off only when
required.
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists