Selecting alsasrc slave-method: resample not implemented?

[Michiel Konstapel]

On 02-11-2022 17:29, Arun Raghavan wrote:
> On Fri, 28 Oct 2022, at 4:36 AM, Michiel Konstapel via gstreamer-devel wrote:
>> I am trying to select the most appropriate pipeline clock for multiple
>> long running capture/streaming pipelines, each capturing multiple audio
>> sources and one video source. By default, the pipeline selects the
>> clock from an alsasrc, but I have noticed that this drifts noticeably
>> over the course of several hours (I've seen about 40 ppm, so 150 ms per
>> hour). Instead, I figured GstNetClientClocks synced to the server would
>> be more appropriate for long-term stable timekeeping. However, that led
>> me to look into how to clock the alsasrc. Documentation on the effect
>> of the various slave-methods is quite limited, but "resample" sounds
>> the most accurate/stable/smooth? However, source diving appears to
>> indicate that resample isn't actually implemented, and uses "skew"
>> instead:
> One way to manage this is to use `drift-tolerance` and `alignment-threshold` to effectively limit the size of discontinuity introduced (at the "cost" of making more frequent adjustments).

Thank you, but these are properties on sinks, right? I am looking for 
something similar on the audio source, but I don't think that exists. I 
am currently experimenting with using the GstSystemClock and 
use-driver-timestamps=false on alsasrc, which appears to sound good so far.