<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’m still experiencing audible glitches when source and playback pipelines use the system clock. It’s unacceptable for an audio application. <o:p></o:p>I haven’t gotten any responses here – can someone PLEASE help me figure out a solution to this problem? Example pipelines are provided below.<o:p></o:p><o:p> </o:p>The system consists of two computers (“server” and “client”) with audio sent via RTP/UDP over a LAN. There are two DACs on the client that I need to keep tightly synchronized, meaning 100usec or less but the audio problems happen even if there is only one DAC. I included below my previous post to this list about this problem from a couple of weeks ago.<o:p></o:p><o:p> </o:p># GST_ARGS on server:<o:p></o:p># alsasrc device='dsnoop:CARD=Loopback,DEV=1' provide-clock=false ! queue ! audioconvert ! audio/x-raw,format=S16LE ! deinterleave name=input \<o:p></o:p>audiointerleave name=client0_output latency=10000000 ! rtpL16pay ! udpsink host=192.168.10.101 port=1234 \<o:p></o:p>input.src_1 ! queue ! tee name=input_ch1 \<o:p></o:p>input.src_0 ! queue ! tee name=input_ch0 \<o:p></o:p>input_ch0. ! queue ! audioconvert ! 'audio/x-raw,channel-mask=(int)-3' ! client0_output.sink_0 \<o:p></o:p>input_ch1. ! queue ! audioconvert ! 'audio/x-raw,channel-mask=(int)-3' ! client0_output.sink_1 \<o:p></o:p>audiomixer name=client0_mixer2 latency=50000000 ! queue ! audioconvert ! 'audio/x-raw,channel-mask=(int)-3' ! client0_output.sink_2 \<o:p></o:p>input_ch0. ! queue ! audioconvert ! client0_mixer2. \<o:p></o:p>input_ch1. ! queue ! audioconvert ! client0_mixer2. <o:p></o:p><o:p> </o:p><o:p> </o:p># GST_ARGS on client 0:<o:p></o:p># udpsrc port=1234 caps='application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)L16, channels=(int)3, payload=(int)96' ! \<o:p></o:p>rtpjitterbuffer latency=80 mode=1 do-lost=true do-retransmission=true ! rtpL16depay ! queue ! audioconvert ! audio/x-raw,format=S32LE ! deinterleave name=input \<o:p></o:p>audiointerleave name=output1 latency = 10000000 ! audioconvert ! audio/x-raw,format=S16LE ! \<o:p></o:p>alsasink device='hw:CARD=DAC,DEV=0' provide-clock=false drift-tolerance=10 slave-method=resample buffer-time=50000 \<o:p></o:p>audiointerleave name=output0 latency = 10000000 ! audioconvert ! audio/x-raw,format=S16LE ! \<o:p></o:p>alsasink device='hw:CARD=DAC_1,DEV=0' provide-clock=false drift-tolerance=10 slave-method=resample buffer-time=50000 \<o:p></o:p>input.src_0 ! queue ! audioconvert ! ladspa-acdf-so-acdf type=22 fp=125 qp=1.0 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x1' ! output0.sink_0 \<o:p></o:p>input.src_1 ! queue ! audioconvert ! ladspa-acdf-so-acdf type=22 fp=125 qp=1.0 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x2' ! output0.sink_1 \<o:p></o:p>input.src_2 ! queue ! audioconvert ! ladspa-acdf-so-acdf type=21 fp=120 qp=0.707 ! \<o:p></o:p>ladspa-acdf-so-acdf type=21 fp=120 qp=0.707 ! ladspa-acdf-so-acdf type=28 db=-6 fp=35 qp=1.0 fz=50 qz=0.5 ! audioconvert ! audio/x-raw,format=S32LE ! tee name=subs \<o:p></o:p>subs. ! queue ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x1' ! output1.sink_0 \<o:p></o:p>subs. ! queue ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x2' ! output1.sink_1<o:p></o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'>From: gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> On Behalf Of Charlie Laub Sent: Thursday, March 1, 2018 7:53 AM To: gstreamer-devel@lists.freedesktop.org Subject: audio glitches when audio sinks are synchronized to GstSystemClock <o:p></o:p></div></div><o:p> </o:p>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>