GNOME Bugzilla – Bug 597749
[pulsesink] audio clock is inaccurate
Last modified: 2012-10-04 15:38:07 UTC
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.
Wim told me that this is a known pulseaudio bug. Indeed I can confirm that alsasink using PA through ALSA emulation has the same issue. So, where's the workaround for this? Having a decent VoIP call is impossible with this bug around. In fact, it renders pulseaudio unusable for GStreamer.
I'm not sure the problem is 100% on pulseaudio side. It looks like pulsesink doesn't wait for the uncork to be completed (when I set wait to TRUE it just hangs?!). I see the first latency_update with a non-zero read index coming in ~120ms after the uncork is initiated (which is done on the first write). This looks reasonable to me, assuming that pulseaudio gets the automatic timing update every 100ms. I'm starting to think that maybe pulseaudio cannot provide accurate timing because it should not. Wouldn't it be more logical that clock drift compensation would be done in pulseaudio itself?
Just adding some observations from testing here - in recent core/base (0.10.31), I don't see the glitches that you are talking about in pulsesink. I do see this with alsasink going through PA, however. Side note: we now uncork the stream after getting enough data to push out.
Is there anything left to fix on the GStreamer side?
The problem isn't anymore as bad as it used to be. The only thing remaining is the infamous single glitch at the beginning of a live pipeline (there is always one and exactly one skew correction kicking in during the first second). Maybe Wim has some experimental pulseaudio/ALSA changes that can be used to try this out.
Ping?
René, do you still see this? With audiotestsrc is-live=true ! pulsesink I don't see any skew correction warnings
It seems to be fixed. I can still see the messages and hear a glitch very rarely, but it's not a real-time system (so this is probably fine).
(Changing to OBSOLETE since we don't really know what fixed it when etc.)