[Bug 795442] New: audiobasesrc: Skew slave method only skew in one direction

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=795442

            Bug ID: 795442
           Summary: audiobasesrc: Skew slave method only skew in one
                    direction
    Classification: Platform
           Product: GStreamer
           Version: unspecified
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: nicolas at ndufresne.ca
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.