[Bug 794762] rtpbin: updating ts_offset often cause audio glitches when using ntp-sync=true

[GStreamer (GNOME Bugzilla)]

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

Charlie Laub <virtually_me at claub.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |virtually_me at claub.net

--- Comment #3 from Charlie Laub <virtually_me at claub.net> ---
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.

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