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.
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]