alsasrc use-driver-timestamps (was: Selecting alsasrc slave-method: resample not implemented?)

[Michiel Konstapel]

So I am continuing my search for how to get the best audio quality in 
combination with long term stability for network streaming, because the 
alsasrc clock drifts too much and the skew method leads to crackling in the 
audio signal.


This leads me to alsasrc use-driver-timestamps: do I want it, and how do I 
get it?


I see alsasrc has a property by that name, but as far as I can tell it has 
*no effect*, because gst_alsasrc_change_state always sets it to FALSE, and 
only sets it back to TRUE when
- the pipeline clock is GstSystemClock
- it is GST_CLOCK_TYPE_MONOTONIC


However, for subclasses of GstSystemClock, such as GstNetClientClock, this 
will never match, so it will never use driver timestamps.


Is this correct?
Is this good/bad? Why would I want or not want driver timestamps?


Cheers,
Michiel

On Friday 28 October 2022 10:36:20 (+02:00), Michiel Konstapel 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:


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/20221101/81573040/attachment.htm>