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