linux-kernel - Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 05 Nov 2018 17:11:47 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Mike Brady <mikebrady@...com.net>
Cc:     Stefan Wahren <stefan.wahren@...e.com>, devel@...verdev.osuosl.org,
        alsa-devel@...a-project.org, f.fainelli@...il.com,
        julia.lawall@...6.fr, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, eric@...olt.net,
        linux-rpi-kernel@...ts.infradead.org,
        nishka.dasgupta_ug18@...oka.edu.in,
        Kirill Marinushkin <k.marinushkin@...il.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay

On Mon, 05 Nov 2018 16:57:07 +0100,
Mike Brady wrote:
> 
> > One another thing I'd like to point out is that the value given in the
> > patch is nothing but an estimated position, optimistically calculated
> > via the system timer.  Mike and I had already discussion in another
> > thread, and another possible option would be to provide the proper
> > timestamp-vs-hwptr pair, instead of updating the timestamp always at
> > the status read.
> 
> Agreed — that would give the caller the information needed to do the
> interpolation for themselves if desired.

And now I wonder whether the problem is still present with the latest
code.  There was a (kind of) regression in this regard when we
introduced the fine-grained hardware timestamping, but it should have
been addressed by the commit 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71
    ALSA: pcm: update tstamp only if audio_tstamp changed

Could you double-check whether the tstamp field gets still updated
even if no hwptr (and delay) is changed?


thanks,

Takashi