sw_params for a direct-ed(dmix) hw pcm

[Pierre-Louis Bossart]

On 3/28/20 3:37 PM, sylvain.bertrand at gmail.com 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.