Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4093668imm; Mon, 30 Jul 2018 08:33:39 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdu4PLq8uUe4xGSMC3/GftFtW/IJZk+gDzuXzF4IPbG8oTtj/VhHPHTA1l9VZzm2MSeGshW X-Received: by 2002:a63:6383:: with SMTP id x125-v6mr16877345pgb.127.1532964819284; Mon, 30 Jul 2018 08:33:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532964819; cv=none; d=google.com; s=arc-20160816; b=KZn4GyKMWHJ0aT4QBnUmZFemRWfV+zclWLz6lvA3g513SMOouTMFmUbMnI0t9CqQUN N3cIC00iKsSWiNHYDAc0ou1lJClM6bvbDoH5CA8XAQID14MZP7+vP8g0lUH6uSGK4jNg bNlsG7MUukpyqfvFDWD9k8b08veyG3v8dY9A9blLIQL9RK5jt2hYsvqx4OyF8/a7hjkz 2Wdn9lco1Y/IUTCSn1eNcBc77AK81Gmw84zA1lvFn4wDZ55IbiMVegMneYLyeY1zCTnf fwK004Zlq6B7WlSGIhe4197PHYtMWTgRLATs7s27yPCEoipED0hyVD5HvFWzoAuMY4Uj z48A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date :arc-authentication-results; bh=IloQJSYYuZ93LrnRLSRBHUuH0QBvzoquwifnVn+Uf9Q=; b=Ai+MQ0rhVN51aAUxjeFfLgajf/m/d1A5M2oAKAQU5VIWJH9596o4E2zk77ZZFbQD2V J8cUZvdex/wCGc8J4uV/7i2CMcvTSjSrmf6hqeWPgKTknRDH20pc0pkAsFseseN5LoM7 +SpXDglognsnia3F03mKUIn5tokG1CFGKa3VDKkp/TNEtSPZlgpf5GM7UQX/geZQcSWd Rki0xYxFjrC6OCPUgF5qubklvokwqEA+3S2N7GzcSrD66W6GSMAkSiFzIaqcfwWm94ic FwO2U2lIFAvchVDW6TAHLU4E2y/lyqjxPbvgKjQZP3/wCCMtVkac1Au2+G96OMQdtUhU BF2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a1-v6si10352616pld.63.2018.07.30.08.33.24; Mon, 30 Jul 2018 08:33:39 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727509AbeG3RHz (ORCPT + 99 others); Mon, 30 Jul 2018 13:07:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:49070 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726623AbeG3RHz (ORCPT ); Mon, 30 Jul 2018 13:07:55 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 12808ADE7; Mon, 30 Jul 2018 15:32:23 +0000 (UTC) Date: Mon, 30 Jul 2018 17:32:21 +0200 Message-ID: From: Takashi Iwai To: "Pierre-Louis Bossart" Cc: "Akshu Agrawal" , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , , , "Liam Girdwood" , "Mark Brown" , "open list" Subject: Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function In-Reply-To: References: <1532686422-1790-1-git-send-email-akshu.agrawal@amd.com> <66c8b8c4-bdd0-0129-5e5b-850890cfdb8d@linux.intel.com> 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Jul 2018 17:15:44 +0200, Pierre-Louis Bossart wrote: > > On 7/27/18 11:28 PM, Agrawal, Akshu wrote: > > > > > > On 7/27/2018 8:39 PM, Pierre-Louis Bossart wrote: > >> On 7/27/18 5:13 AM, Akshu Agrawal wrote: > >>> There are cases where a pointer function populates > >>> runtime->delay, such as: > >>> ./sound/pci/hda/hda_controller.c > >>> ./sound/soc/intel/atom/sst-mfld-platform-pcm.c > >>> > >>> Also, in some cases cpu dai used is generic and the pcm > >>> driver needs to set delay. > >>> > >>> This delay was getting lost and was overwritten by delays > >>> from codec or cpu dai delay function if exposed. > >> > >> Humm, yes the runtime->delay set in the .pointer function would be lost > >> without this change, but the delay would still be provided in the > >> followup call to .delay. > >> With your change, the same delay will be accounted for twice? > >> > > > > It will not be accounted twice because no driver which is setting > > runtime->delay is defining .delay op for cpu_dai. Vice versa is also > > true, the drivers which define .delay for cpu_dai don't set > > runtime->delay. And I think this is expected from drivers else it would > > be a bug from their side. > > what do you mean my 'no driver'? Can you clarify if this is based on > analysis of the code or by-design. I don't recall having seen any > guidelines on this topic, and it's quite likely that different people > have different interpretation on how delay is supposed to be reported. Currently the problem seems to be the ambiguity of delay callback. Through a quick glance, Akshu's patch looks correct to me. The delay value that was calculated in some drivers aren't taken properly because the current soc_pcm_pointer() presumes that the delay calculation is provided *only* by delay callback. The two drivers suggested in the patch set runtime->delay in its pointer callback, and these values are gone. That said, if delay callback of CPU dai provides the additional delay, the patch does correct thing. OTOH, if CPU dai provides the base delay instead, we need to clarify that it's rather a must; the delay calculation in pointer callback becomes bogus in this scenario. thanks, Takashi > > > > > .delay for codec_dai anyway is different and has to be accounted for. > > > > Thanks, > > Akshu > >>> > >>> Signed-off-by: Akshu Agrawal > >>> --- > >>> sound/soc/soc-pcm.c | 5 ++++- > >>> 1 file changed, 4 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c > >>> index 98be04b..b1a2bc2 100644 > >>> --- a/sound/soc/soc-pcm.c > >>> +++ b/sound/soc/soc-pcm.c > >>> @@ -1179,6 +1179,9 @@ static snd_pcm_uframes_t soc_pcm_pointer(struct snd_pcm_substream *substream) > >>> snd_pcm_sframes_t codec_delay = 0; > >>> int i; > >>> + /* clearing the previous delay */ > >>> + runtime->delay = 0; > >>> + > >>> for_each_rtdcom(rtd, rtdcom) { > >>> component = rtdcom->component; > >>> @@ -1203,7 +1206,7 @@ static snd_pcm_uframes_t > >>> soc_pcm_pointer(struct snd_pcm_substream *substream) > >>> } > >>> delay += codec_delay; > >>> - runtime->delay = delay; > >>> + runtime->delay += delay; > >>> return offset; > >>> } > >>> > >> > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel@alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > >