<html><head></head><body><span class="viv-signature"></span>Forgive me for 
ranting.... These undocumented and unimplemented methods/properties 
make me worry: am I just looking for ghosts? Does this all Just Work for 
everyone and should I just leave things at the defaults and move on? Many 
elements expose properties that seem like they involve important tradeoffs 
to make given a specific use case, but then give no information on what the 
various options do and especially *why/when* you would want them. Although 
they seem important, they are hardly mentioned on the mailing list. Source 
diving sometimes turns up some code or comments, or sometimes it just turns 
out that the exposed knob doesn't even do anything :-/ Does this mean I 
have ventured into an area where I'm not supposed to be, or is this 
legitimately missing functionality/documentation?<div><br></div><div>Not 
saying that I don't hugely appreciate all the work that's gone into 
gstreamer, and I love hacking on this stuff, but boy does it get 
frustrating at times!</div><div><br></div><div>All the 
best,</div><div>Michiel<br><br>On Tuesday 01 November 2022 10:58:26 
(+01:00), Michiel Konstapel wrote:<br><br><blockquote style="margin: 0 0 
0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><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="padding-left:1ex;border-left-color:rgb(0, 
0, 
255);border-left-style:solid;border-left-width:2px;margin-left:0px;margin-bottom:0.8ex;margin-right:0px;margin-top:0px;">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></blockquote><span 
class="viv-signature-below"><br></span></div></body></html>