[gstreamer-bugs] [Bug 597749] New: [pulsesink] audio clock is inaccurate

[GStreamer (bugzilla.gnome.org)]

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

           Summary: [pulsesink] audio clock is inaccurate
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: mail at renestadler.de
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Pulsesink seems to have some problems determining what the internal stream time
is. It shows up negatively when it is slaved to a different clock and the skew
algorithm has to kick in:

$ GST_DEBUG=2 gst-launch-0.10 audiotestsrc is-live=true ! pulsesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
0:00:00.017263543 14755      0x1d96030 WARN                     bin
gstbin.c:2312:gst_bin_do_latency_func:<pipeline0> failed to query latency
New clock: GstSystemClock
0:00:00.156788119 14755      0x1f5ab70 WARN           baseaudiosink
gstbaseaudiosink.c:1028:gst_base_audio_sink_skew_slaving:<pulsesink0> correct
clock skew -11298628 < -10000000
0:00:00.403085040 14755      0x1f5ab70 WARN           baseaudiosink
gstbaseaudiosink.c:1028:gst_base_audio_sink_skew_slaving:<pulsesink0> correct
clock skew -10319104 < -10000000
0:00:00.737286961 14755      0x1f5ab70 WARN           baseaudiosink
gstbaseaudiosink.c:1028:gst_base_audio_sink_skew_slaving:<pulsesink0> correct
clock skew -10134766 < -10000000
0:00:01.341005566 14755      0x1f5ab70 WARN           baseaudiosink
gstbaseaudiosink.c:1028:gst_base_audio_sink_skew_slaving:<pulsesink0> correct
clock skew -10418319 < -10000000

(there's noticable clicks in the audio in the beginning)

In about 98% of the cases, audio plays normal after that. In the remaining 2%,
it ends up in a loop of pulse stream underruns from which it cannot recover. I
guess that has something to do with the skew slaving adjusting the sample
position.

I'm having the feeling that pa_stream_get_time() doesn't work as expected or is
misused. I think it's suspicious that the internal time is 0 until the playback
buffer is filled up initially (the first skew correction happens during that
time already). Also, after when the drift seems stabilized, the skew oscillates
between +/-7ms still.

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