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

[Michiel Konstapel]

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!


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/-/issues/438 
sounds like a potential problem.

Kind regards,
Michiel






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20221101/8e3e0014/attachment-0001.htm>