<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style></style></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1>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.<o:p></o:p><o:p> </o:p>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).<o:p></o:p><o:p> </o:p>I would like to force continual resampling to the system clock so I use the following sink properties: <o:p></o:p>provide-clock=false <o:p></o:p>slave-method=resample or skew<o:p></o:p>drift-tolerance to 1 or 10 (nanoseconds) <o:p></o:p><o:p> </o:p>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. <o:p></o:p><o:p> </o:p>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. <o:p></o:p><o:p> </o:p>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?<o:p></o:p></div></body></html>