Selecting alsasrc slave-method: resample not implemented?

[Arun Raghavan]

On Fri, 4 Nov 2022, at 11:19 AM, Michiel Konstapel wrote:
> 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.

Right, on the source, you're basically timestamping based on what the device provides, or what your pipeline clock reading is when the buffer arrives. Any adjustments you want to make based on those timestamps vs. render time happens at the point of render (either sinks, or audiomixer or such).

Cheers,
Arun