[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8b48b17d-3751-c027-7b66-fbea3b5a412f@ti.com>
Date: Mon, 10 Feb 2020 16:59:28 +0200
From: Peter Ujfalusi <peter.ujfalusi@...com>
To: Mark Brown <broonie@...nel.org>
CC: Takashi Iwai <tiwai@...e.de>, <lgirdwood@...il.com>,
<tiwai@...e.com>, <perex@...ex.cz>, <lars@...afoo.de>,
<alsa-devel@...a-project.org>, <vkoul@...nel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: dmaengine_pcm: Consider DMA cache caused delay in
pointer callback
On 10/02/2020 16.37, Mark Brown wrote:
> On Mon, Feb 10, 2020 at 04:28:44PM +0200, Peter Ujfalusi wrote:
>> On 10/02/2020 16.21, Takashi Iwai wrote:
>
>>>> delay += codec_delay;
>>>>
>>>> - runtime->delay = delay;
>>>> + runtime->delay += delay;
>
>>> Is it correct?
>>> delay already takes runtime->delay as its basis, so it'll result in a
>>> double.
>
>> The delay here is coming from the DAI and the codec.
>> The runtime->delay hold the PCM (DMA) caused delay.
>
> I think Takashi's point here (and a query I have) is that we end up with
>
> delay = runtime->delay;
> delay += stuff;
> runtime->delay += delay;
>
> which is equivalent to
>
> runtime->delay = (runtime->delay * 2) + stuff;
>
> and that's a bit surprising.
I see, I have missed what
9fb4c2bf130b ASoC: soc-pcm: Use delay set in component pointer function
did.
the soc-pcm part of the patch can be dropped then.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Powered by blists - more mailing lists