Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 31 Jul 2018 15:29:35 +0200
Message-ID: <s5hin4vpm80.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Mark Brown <broonie@kernel.org>
Cc:     "Agrawal, Akshu" <Akshu.Agrawal@amd.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@alsa-project.org>, Alexander.Deucher@amd.com,
        djkurtz@chromium.org, Liam Girdwood <lgirdwood@gmail.com>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function
In-Reply-To: <20180731131246.GC5719@sirena.org.uk>
References: <e0990b62-897c-6dc7-8ac9-296932c505b7@amd.com>
        <dd4d3dc6-88f3-d53f-cd5c-5035c80be3da@linux.intel.com>
        <s5hy3dsviwq.wl-tiwai@suse.de>
        <20180730155030.GP5789@sirena.org.uk>
        <7a88c7b4-d31d-b044-bb8e-a866d49d1256@amd.com>
        <s5hwotc0y6v.wl-tiwai@suse.de>
        <5b3249cb-6212-6a14-b644-7548cf0ad00c@amd.com>
        <s5ha7q721vs.wl-tiwai@suse.de>
        <20180731101943.GB5719@sirena.org.uk>
        <s5heffjr8ys.wl-tiwai@suse.de>
        <20180731131246.GC5719@sirena.org.uk>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/26
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 31 Jul 2018 15:12:46 +0200,
Mark Brown wrote:
> 
> On Tue, Jul 31, 2018 at 12:32:59PM +0200, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > However since it's not supposed to be providing any DMA a CPU DAI really
> > > shouldn't be doing this...
> 
> > Well, if so, the CPU dai also cannot get the exact base delay
> > corresponding to the reported position, either, no?
> 
> It can know how much delay it's adding internally between its input and
> output, which feeds into the overall delay experienced by the user.

But isn't it merely the additional delay that should be applied on top
of the existing runtime->delay?


Takashi