<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>