<html><head></head><body><span class="viv-signature"></span>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.<div><br></div><div>This leads me to alsasrc
use-driver-timestamps: do I want it, and how do I get
it?</div><div><br></div><div>I see alsasrc has a property by that name, but
as far as I can tell it has *no effect*,
because <code>gst_alsasrc_change_state</code> always sets it to
FALSE, and only sets it back to TRUE when</div><div>- the pipeline clock is
GstSystemClock</div><div>- it is
GST_CLOCK_TYPE_MONOTONIC</div><div><br></div><div>However, for subclasses
of GstSystemClock, such as GstNetClientClock, this will never match, so it
will never use driver timestamps.</div><div><br></div><div>Is this
correct?</div><div>Is this good/bad? Why would I want or not want driver
timestamps?</div><div><br></div><div>Cheers,</div><div>Michiel</div><div><br>On
Friday 28 October 2022 10:36:20 (+02:00), Michiel Konstapel
wrote:<br><br><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF
2px solid; padding-left: 1ex">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:<div><br></div><div><a
href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/audio/gstaudiobasesrc.c#L869">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/audio/gstaudiobasesrc.c#L869</a></div><div><pre
lang="c" class="code highlight"><span class="line" data-testid="content"
lang="c" id="LC866"><span class="hljs-keyword"> if</span>
(!GST_CLOCK_TIME_IS_VALID (rb_timestamp) && clock != src->clock)
{</span>
<span class="line" data-testid="content" lang="c" id="LC867"> <span
class="hljs-comment">/* we are slaved, check how to handle this
*/</span></span>
<span class="line" data-testid="content" lang="c" id="LC868"> <span
class="hljs-keyword">switch</span> (src->priv->slave_method) {</span>
<span class="line" data-testid="content" lang="c" id="LC869"> <span
class="hljs-keyword">case</span> GST_AUDIO_BASE_SRC_SLAVE_RESAMPLE:</span>
<span class="line" data-testid="content" lang="c" id="LC870"> <span
class="hljs-comment">/* Not implemented, use skew algorithm. This algorithm
should</span></span>
<span class="line" data-testid="content" lang="c" id="LC871"> *
work on the readout pointer and produce more or less samples based</span>
<span class="line" data-testid="content" lang="c" id="LC872"> * on
the clock drift */</span>
<span class="line" data-testid="content" lang="c" id="LC873"> <span
class="hljs-keyword">case</span> GST_AUDIO_BASE_SRC_SLAVE_SKEW:</span>
</pre><span class="viv-signature-below"><div><span
class="viv-signature-below"><br></span></div>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.<br><br>Kind
regards,</span></div><div><span
class="viv-signature-below">Michiel<br><br></span></div></blockquote><span
class="viv-signature-below"><br><br></span></div></body></html>