On 3/28/20 3:37 PM, sylvain.bertrand@xxxxxxxxx wrote:
On Sat, Mar 28, 2020 at 02:15:34PM -0500, Pierre-Louis Bossart wrote:I don't think it's possible unless the timestamps are taken really close to each other. There was some work some by Chris Hall in 2016 to revisit how the conversions were done and the past taken into account is a couple of ms, see ("time: Add history to cross timestamp interface supporting slower devices"). if your device is "shared", which implies a mixer, the notion of precise timestamps is rather questionable so you might be able to get-by with local interpolation in your plug-ins. Trying a full-blown conversion of the kernel-reported time is not really useful if the mixing granularity is in the ms range or more. FWIW you also want to take MONOTONIC_RAW with a grain of salt. In a corner case w/ long tests lasting 48 hours we saw the timestamps reported by the kernel drift over time. the drift was minor (double-digit ppb - yes parts per billion) but the fixed-point math for the counters at some point impacts the results. Reading directly the TSC from userspace and doing floating-point math bypassed the rounding errors.This is how I got into this: I was writting a naive audio application and arrived at the point I needed timing information to do exactly that, a rough, but enough, audio linear interpolation (with ffmpeg timestamp). I naively configured alsa to use monotonic_raw, because avoiding ntp for audio timing was a good idea, and when I did sample on my side the monotonic raw clock, I realised that everything was off 100s of ms (alsa defaults to monotonic and ignores monotonic_raw setting in the case of a shared device). I followed the white rabbit, and here I stand. The cherry on top was the inconsistency about the trigger timestamp (which is not meant to be close to the other timestamps). This pushes to fix snd_pcm_sw_params_set_tstamp_type(): recursive along a pcm plugin "pipeline" and return an error in the case of a setting difference from the one chosen by dmix. I am not confident at all since I have only a minimal perspective on alsa.
Using MONOTONIC_RAW is very nice on paper, until you realize you can't program a timer using the information. You can only read the timestamp and not really do much if you want to sleep/wait.
In practice, if you really really need super-precise information you'll get use rdtsc(), and apply you own formulas. And otherwise stick with MONOTONIC, it's rather unlikely you will ever notice the NTP changes. PulseAudio, CRAS and a number of Android HALs use MONOTONIC and nobody ever complained.
