Audio glitches when using external clock
When syncing to an external clock (eg. NTP) using the resample
slave method, there are regular hiccups in the audio.
By digging through the traces, I was able to determine that those hiccups occur each time the NTP clock is sampled to update the GstAudioSinkClock
. In particular, using GST_DEBUG="audiobasesink:7"
and looking at the traces that show how each buffer is resampled (traces like gstaudiobasesink.c:2134:gst_audio_base_sink_render:<alsasink0> rendering at 9471 480/480
), I was able to determine that most buffers are stretched by a small amount (eg. between 480 and 490 frames instead of 480) but the first buffer after each sampling of the NTP clock is reduced by a large amount (often to less than 400 frames instead of 480) producing the audible artefact.
In gstaudiobasesink.c
there is a disabled code block like this near line 1358:
/* FIXME, we can sample and add observations here or use the timeouts on the
* clock. No idea which one is better or more stable. The timeout seems more
* arbitrary but this one seems more demanding and does not work when there is
* no data comming in to the sink. */
#if 0
GstClockTime etime, itime;
gdouble r_squared;
/* sample clocks and figure out clock skew */
etime = gst_clock_get_time (GST_ELEMENT_CLOCK (sink));
itime = gst_audio_clock_get_time (sink->provided_clock);
/* add new observation */
gst_clock_add_observation (sink->provided_clock, itime, etime, &r_squared);
#endif
I was able to fix the issue by enabling the above code block and disabling the call to gst_clock_set_master (sink->provided_clock, clock);
near line 1685. Afterwards, all buffers are resampled to values close to the nominal 480 frames (between 477 and 483) and there are no longer any audible artefacts.