On 3/28/20 1:26 PM, sylvain.bertrand@xxxxxxxxx wrote:
On Fri, Mar 27, 2020 at 10:40:06AM +0100, Jaroslav Kysela wrote:
Yes, it's a bug which should be fixed in dmix instead to use a workaround in
the app. The easiest way is to return an error in set sw_params, but it may
cause problems for the app which assumes that this timestamp mode can be set
freely. Perhaps, we can add a timestamp translation layer (not easy, I
know).
I understand that, in the case of a shared hw, reasonable defaults should be
enforce to avoid that any audio application which would be first to configure
this hw and throwing some audio configuration tantrum, forces it upon all the
other audio applications (this is the answer to "why has dmix some defaults?").
Speaking strictly, snd_pcm_sw_params_set_tstamp_type() has a return
value, namely application code must expect a return code which could be an
error code. Additionnaly an audio app using the kernel interface/a hw plugin
pcm, would have to track anyway the type of timestamp clock at the time of state
change: the trigger timestamp of a kernel status ioctl used the type of
timestamp clock at the time of the state change, not the type of timestamp
clock provided in the ioctl (btw, what about some documentation addition?).
In the use case of a shared device, it seems the right way would be to send an
error back to the application (aka "making snd_pcm_sw_params_set_tstamp_type()
recurse down the plugin pipeline"), because after giving some thoughts about it
I don't see how it is possible to convert a timestamp from one clock type to
another: backlog all adjtime deltas, plus the initial values, plus any natural
drift? The linux devs in charge of time keeping may be able to answer this.
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.
