[Bug 795443] New: audiobasesrc: Re-timestamp slave method introduce latency

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 795443
           Summary: audiobasesrc: Re-timestamp slave method introduce
                    latency
    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: ---

So, to workaround https://bugzilla.gnome.org/show_bug.cgi?id=795442 I started
using re-timestamp slave method. As I'm using an audiomixer or an
audiointerleaver downstream, I can rely on these to handle the skew for me. So
this method worked in maintaining a constant latency. The problem that I faces
though is that between the first and the second called to
GstAudioBaseSrc:create() there is a large delay (around 130ms in my case).

  read(sample 0)
130ms later ...
  read(sample 1)

As the segtotal is pretty large (320ms) all this data get buffered in the
ringbuffer, and remains. I've made a quick hack to get going, basically I would
never let the read-head be further then 2 segments from the most recent, but
this had a side effect, which is that the audio source can no longer accumulate
latency.

If it wasn't of the re-timestamp, what would happen is that all buffered
segments would get pushed, but would be late according to their timestamp, but
with the re-timestamp, which is a bit of a hack method really, they all will be
right on time. Investigating this delay seems useful, but it would be nice to
improve the re-timestamp slave method so it does not have this side effect.

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