[Bug 644945] New: Gstreamer audio synchronization fails at low latency.

[GStreamer (bugzilla.gnome.org)]

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

           Summary: Gstreamer audio synchronization fails at low latency.
    Classification: Desktop
           Product: GStreamer
           Version: 0.10.32
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: blaise at suitabletech.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
      GNOME target: ---
     GNOME version: ---


The following pipeline usually fails to play sound on the ubuntu lucid desktops
I have tried:
{{{
rosrun gstreamer gst-launch alsasrc latency-time=10000 ! alsasink
buffer-time=20000 latency-time=10000
}}}

Folks on my team are also getting similar problems with drivers other than
alsa, but I don't have hard data yet on what is going on in those cases.

As far as I can tell, the problem is that the alsasink is stuffing data into
libasound as fast as it can, and libasound is willing to buffer a lot more than
10ms worth of data. Hence, the read pointer in the ring buffer gets ahead of
the write pointer, and all you hear is silence.

I am basing this interpretation on the following observations:
- When playback starts, you see a bunch of reading from the ring buffer.
- Before the batch of reads, diff is positive, after the batch of reads diff is
negative (so everything gets dropped).
- The delay goes way up during the batch of reads.

I believe the correct way to fix this is for gst_ring_buffer_prepare_read to
check if a segment is available, check the current delay on the audio device,
and if the delay on the audio device is sufficient, wait on the ring buffer
condition variable. Similarly the commit method should notify the condition
variable to wake up the reading thread.

I would be interested in any comments on this approach, and hope to be
providing a patch to fix this.

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