Selecting alsasrc slave-method: resample not implemented?

[Michiel Konstapel]

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:


https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/audio/gstaudiobasesrc.c#L869
   
if (!GST_CLOCK_TIME_IS_VALID (rb_timestamp) && clock != src->clock) {
     /* we are slaved, check how to handle this */
     switch (src->priv->slave_method) {
       case GST_AUDIO_BASE_SRC_SLAVE_RESAMPLE:
         /* Not implemented, use skew algorithm. This algorithm should
          * work on the readout pointer and produce more or less samples 
based
          * on the clock drift */
       case GST_AUDIO_BASE_SRC_SLAVE_SKEW:



Am I correct? And should I worry about discontinuities from the skew 
algorithm? How often and how big are the jumps it will introduce? 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/438 
sounds like a potential problem.

Kind regards,
Michiel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20221028/927b2016/attachment.htm>