audio glitches when audio sinks are synchronized to GstSystemClock

Charlie Laub charleslaub at sbcglobal.net
Thu Mar 1 15:52:31 UTC 2018


I am experiencing some behavior that seems to originate in how slaving is
implemented in GstAudioBaseSink. I'd like some help in tracking this down
and then issuing a bug report if that is necessary.

 

My playback pipeline uses GstSystemClock as the clock source. The reason for
this clock source is so that I can use multiple alsa sinks (e.g. two or more
stereo DACs) and have playback closely synchronized between them. The system
clock is NTP disciplined to a local stratum 1 server. The problem I am
experiencing happens no matter how many alsa sinks the pipeline is playing
to (e.g. even with one sink).

 

I would like to force continual resampling to the system clock so I use the
following sink properties: 

provide-clock=false 

slave-method=resample or skew

drift-tolerance to 1 or 10 (nanoseconds) 

 

I am experiencing various audible glitches. With skew, there is a small tick
or pop sound that occurs relatively frequently, every couple of seconds.
When audio is muted (sending zeros) the noise is gone, so I assume this is
the playback pointer being changed when sample values are non-zero. With the
slave-method set to resample, the audio is problem-free for longer periods
of time but then there will be several seconds of glitchy audio, which
sounds like the pitch is increasing and decreasing rapidly before normal
playback resumes, or it might last even longer as if the pitch is wavering
all the time. With slave-method set to none, these artifacts disappear until
the inevitable buffer over or underrun problems that produce a discontinuity
(a dropout) in the audio. 

 

I looked through the code and the audio slaving seems to be done within
GstAudioBaseSink. This module (gstaudiobasesink.c) is credited to Erik
Walthinsen in 2000 and to Wim Taymans in 2005. Being somewhat new to
gstreamer I am not all that familiar with the code and all the clock
management related stuff found in that module. 

 

Can someone please help me better document this behavior and issue a bug
report on it, or figure out what might be causing this behavior?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180301/a53081e9/attachment-0001.html>


More information about the gstreamer-devel mailing list