GNOME Bugzilla – Bug 794762
rtpbin: updating ts_offset often cause audio glitches when using ntp-sync=true
Last modified: 2018-11-03 15:27:36 UTC
Following the procedure outlined in the pdf below we have encountered audio glitches in our audio receivers. Have tracked it down to that constantly updating the ts_offset in the rtpbin results in glitches when streaming audio using ntp-sync=true. Seems to be related to jittery behaviour in the local/remote clock causing the ts_offset to be updated often with very small changes (<100 microseconds) which in turn causes the alsasink to jump around in its audio buffer. https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2015/Sebastian%20Dr%C3%B6ge%20-%20Synchronised%20multi-room%20media%20playback%20and%20distributed%20live%20media%20processing%20and%20mixing%20with%20GStreamer.pdf
Created attachment 370242 [details] [review] added option for setting a min_ts_offset threshold
Made a patch where I have introduced a property for setting a minimum ts_offset threshold. If ts_offset is below this value in ntp sync mode, ts_offset is not updated. This removes the small adjustments and subsequently the audio glitches we are experiencing. Have used 1ms as a threshold while testing. This might put our receivers slightly out of sync but in our case this is better than having the glitches. Could we encounter any other issues if handling the glitches in this way? Regards, Danny
Have you tried manually syncing clients (RX) to sender (TX) via NTP, chrony, etc? This is what I do on my systems. I use rtp payloading and depayloading, and send the data in UDP. In the rtpjitterbuffer on all clients, if I set mode=1 (the default, slave receiver to sender clock) I sometimes experience problems. These include dropouts, and then the eventual loss of audio even though sender and receiver pipelines continue to run. If I set mode=4 (assume clocks are synchronized) and use NTP outside of gstreamer to synchronize clocks, I do not experience these problems. I'm not sure what is going on in the code, but perhaps with mode=4 the TS offset is ignored since clocks are supposed to be synced. Also, the NTP clock discipline algorithm may make circa 100usec jumps periodically (e.g. every 60-120 sec depending on time constant). These look like an exponential decay of "offset" followed by a sudden jump in offset, followed by the next exponential decay of offset, etc. It repeats over and over (it is periodic) and looks like a sawtooth or triangle waveform with a period on the order of minutes. Depending on how NTP was adapted into the rtpbin code this may be the source of jitter. If that cannot be eliminated, you need to work around it and one way would be to add a smoothing to clock data. By using smoothed, raw TS or NTP data you can gain some control both over how fast the client responds to changes in its clock AND the amount of jitter reduction. How to do it? A smoothing algorithm could be a simple as moving or exponential averaging, or something like a Savitzky-Golay or Akima fitting algorithm for the last N points, with a focus on slowly changing output that smooths out sudden jumps.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/454.