From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Young Subject: Re: Improving status timestamp accuracy Date: Mon, 6 Jun 2016 10:42:41 +0100 Message-ID: <57554591.20103@gmail.com> References: <5752A005.2050309@gmail.com> <5753FFF0.3050200@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by alsa0.perex.cz (Postfix) with ESMTP id E31B926547F for ; Mon, 6 Jun 2016 11:42:42 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id k184so8592431wme.2 for ; Mon, 06 Jun 2016 02:42:42 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: Raymond Yau , alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org On 06/06/16 09:34, Takashi Iwai wrote: > On Sun, 05 Jun 2016 12:33:20 +0200, > Alan Young wrote: >> Regardless of what value of DMA_RESIDUE_GRANULARITY_xxx that a driver >> claims to support, it is not really defined how fine a burst might >> be. So the end result is, from the point of view of audio, that the >> resulting position obtained by the pointer() call is pretty >> inaccurate. Hence my proposal to attempt to improve the accuracy of >> the pcm_status() result given the above constraints. > Well, the subject appears misleading. What you want isn't the audio > timestamp accuracy. From API POV, the accurate position is calculated > via the (additional) delay. So, what you want is rather the accurate > position delay accounting, and the audio timestamp is merely one of > the ways to achieve that. > Well, yes, you could put it that way. Whether an accurate delay, combined with the associated timestamp, or an accurate audio delay, I would have the data needed to track audio drift from wallclock time. See my response to Raymond for more detail. Alan.