[Bug 650724] New: baseaudiosink: delay the resyncing of timestamp vs ringbuffertime

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=650724
  GStreamer | gst-plugins-base | git

           Summary: baseaudiosink: delay the resyncing of timestamp vs
                    ringbuffertime
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: havard.graff at tandberg.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=188281)
 View: https://bugzilla.gnome.org/attachment.cgi?id=188281
 Review: https://bugzilla.gnome.org/review?bug=650724&attachment=188281

patch

Original ide and design by Felipe Contreras <felipe.contreras at gmail.com>

A common problem for audio-playback is that the timestamps might not be
completely linear. This is specially common when doing streaming over
a network, where you can have jittery and/or bursty packettransmission,
which again will often be reflected on the buffertimestamps.

Now, the current implementation have a threshold (changed in this patch to
"alignment-threshold", and made seperate from the property that set
the tolerance for clock-drift resync) that says how far the
buffertimestamp is allowed o drift from the ideal aligned time
in the ringbuffer. This was an instant reaction, and ment that if one
buffer arrived with a timestamp that would breach the aligment-threshold,
a resync would take place, and the result would be an audible gap for the
listener.

The annoying thing would be that in the case of a "timestamp-outlier", you
would first resync one way, say +100ms, and then, if the next timestamp
was "back on track", you would end up resyncing the other way (-100ms)
So in fact, when you had only one buffer with slightly off timestamping,
you would end up with *two* audible gaps. This is the problem this patch
addresses.

The way to "fix" this problem with the previous implementation, would
have been to increase the "alignment-threshold" to a value that was
greater than the largest timestamp-outlier one would normally expect.
The big problem with this approach, however, is that it will allow
normal operations with a huge offset timestamp vs running-time, which
is detrimental to lip-sync. If the alignment-threshold is set to 200ms, it
basically means that lip-sync can easily end up being off by that much.

This patch will basically start a timer when the first breach of
alignment-threshold is detected. If any following timestamp for the
next n nanoseconds gets "back on track" within the threshold, it has
basically eliminated the effect of an outlier, and the timer is stopped.
 If, however, all timestamps within this time-limit are breaching the
threshold, we are probably facing a more permanent offset in the
timestamps, and a resync is allowed to happen.

So basically this patch offers something as rare as both higher
accuracy, it terms of allowing smaller alignment-thresholds, as well
as much smoother, less glitchy playback!

Adds getters and setters for the configurable alignment-threshold
and discont-time, to allow derived implementations setting these values
upon construction. The defaults are set as to completely mimic the
behavior of the old implementation, only with fewer glitches!

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.