After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795442 - audiobasesrc: Skew slave method only skew in one direction
audiobasesrc: Skew slave method only skew in one direction
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-04-21 19:29 UTC by Nicolas Dufresne (ndufresne)
Modified: 2018-11-03 12:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Dufresne (ndufresne) 2018-04-21 19:29:46 UTC
GstAudioBaseSrc implements a property called slave-method. The default for this is "skew". Similarly to audiobasesink, I believe this is supposed to skew uppon clock drift, regardless of the direction of the drift. Unlike audiobasesink, there is no drift-tolerance configuration.

There is multiple issues in this code, but the main issues right now is that it only handle drift in one situation, if downstream clock is faster. 

The situation I came across, is that when downstream clock is slower, it will never skew, unless ring buffer becomes full. But as soon as you have a queue downstream (I do, because I have a tee), it will never reach that situation. Instead, the latency will start growing, and when all the queues are full, the skew code will never manage to recover, because it does not delay the clock, so when this state is reached, all the audio goes wrong forever.

On the other end, when the downstream clock is faster, it will skew when the ringbuffer reaches segtotal in term of skew duration (nearest value the driver / library have picked around buffer-time property value). This value can be quite big, in fact, on the TI Sitara I get a buffer-time that is 16 time the size of the latency time (20ms), so 320ms. So if downstream clock is faster, it takes several minutes before the skew situation is reached and audio buffer stops being late downstream. But at least it does skew, and does change the output of the associate audioclock. Though, the implementation is racy, as we now have two thread calling ring_buffer_advance at the same time. As a side, the next buffer is often not the one we just capture, but whatever was left there last time we used the segment. This skew method need to be reworked, hence why I think this second detail should be considered.

It's clear in my case that a skew with a tolerance of 320ms and more is not acceptable (I'm using this in a VoIP application).
Comment 1 Nicolas Dufresne (ndufresne) 2018-04-21 19:42:38 UTC
Also, another issue we would look at while at it, there is a hack that we skew on first buffer, but segtotal. This introduce an undeeded startup delay (320ms in my case).
Comment 2 GStreamer system administrator 2018-11-03 12:05:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/438.