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

Nicolas Dufresne nicolas at ndufresne.ca
Tue Nov 1 13:11:05 UTC 2022


Le mardi 01 novembre 2022 à 10:13 +0000, Michiel Konstapel via gstreamer-devel a
écrit :
> 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?
> 
> 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!

I believe commercial implementation, were this strongly matter will change a HW
PLL to adjust the HW clock to their system/network clock. This should happen in
combination of slave-method=none on the source and slave-method=custom on the
sink. Be aware that I have never implemented such an advanced solution myself.

The alternative would be dynamic software resampling, see slave-method=resample
in alsasink, but this has been broken for age, and we don't have anyone working
on it. Audio servers like PipeWire and PulseAudio might already handle this
transparently, that might explain why only alsasrc/sink users reports this.

> 
> All the best,
> Michiel
> 
> On Tuesday 01 November 2022 10:58:26 (+01:00), Michiel Konstapel wrote:
> 
> > 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/-/iss
> > > ues/438 sounds like a potential problem.
> > > 
> > > Kind regards,
> > > Michiel
> > > 
> > 
> > 
> 



More information about the gstreamer-devel mailing list