sw_params for a direct-ed(dmix) hw pcm

[sylvain.bertrand at gmail.com]

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.

-- 
Sylvain