linux-kernel - Re: [PATCH] ALSA: core: Remove trigger_tstamp

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]

Message-ID: <f41762a1-048c-4ab6-86ae-f364753210c7@mailbox.org>
Date: Tue, 13 Aug 2024 15:58:13 +0200
From: Zeno Endemann <zeno.endemann@...lbox.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
 linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 Cezary Rojewski <cezary.rojewski@...el.com>,
 Christian Brauner <brauner@...nel.org>, Mark Brown <broonie@...nel.org>,
 Pavel Hofman <pavel.hofman@...tera.com>, David Howells
 <dhowells@...hat.com>, Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
 Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
 Bard Liao <yung-chuan.liao@...ux.intel.com>,
 Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
 Kai Vehmanen <kai.vehmanen@...ux.intel.com>
Subject: Re: [PATCH] ALSA: core: Remove trigger_tstamp_latched

Takashi Iwai wrote on 13.08.24 15:41:
> On Tue, 13 Aug 2024 14:54:42 +0200,
> Zeno Endemann wrote:
>>
>> Pierre-Louis Bossart wrote on 13.08.24 10:04:
>>> by focusing on the trigger timestamp I think you're looking at the wrong
>>> side of the problem. The timestamping is improved by using the same
>>> hardware counter for the trigger AND regular timestamp during
>>> playback/capture. If you look at a hardware counter during
>>> playback/capture but the start position is recorded with another method,
>>> would you agree that there's a systematic non-reproducible offset at
>>> each run? You want the trigger and regular timestamps to be measured in
>>> the same way to avoid measurement differences.
>>
>> I am not sure what you are talking about. I have not seen any place in the
>> code where the trigger timestamp is taken in any other more sophisticated
>> way than what the default is doing, i.e. calling snd_pcm_gettime. So I do
>> not see how your custom *trigger* timestamps are done "with another method".
>>
>>> I will not disagree that most applications do not need precise
>>> timestamping, but if you want to try to enable time-of-flight
>>> measurements for presence or gesture detection you will need higher
>>> sampling rates and micro-second level accuracy.
>>
>> I don't know, this sounds very theoretical at best to me. However I do not
>> have the desire to try to further argue and convince you otherwise.
>>
>> Do you want to propose a different solution for the stop trigger timestamp
>> bug? That is my main goal after all.
> 
> Ah, I guess that the discussion drifted because of misunderstanding.
> 
> This isn't about the accuracy of the audio timestamp, but rather the
> timing of trigger tstamp.  The commit 2b79d7a6bf34 ("ALSA: pcm: allow
> for trigger_tstamp snapshot in .trigger") allowed the trigger_tstamp
> taken in the driver's trigger callback.  But, the effectiveness of
> this change is dubious, because the timestamp taken in the usual code
> path in PCM core is right after the trigger callback, hence the
> difference should be negligible -- that's the argument.

Exactly. Sorry if my communication was not clear on that.

> 
> No matter how the fix will be, could you put the Fixes tag pointing to
> the culprit commit(s) at the next submission?

Will do. I guess I'll have to look up which commit actually enabled the
trigger_tstamp_latched in hda, as 2b79d7a6bf34 has no driver using that
yet, so is not technically the culprit?