<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" style='word-wrap:break-word'><div class=WordSection1>I have been developing and measuring the performance of a streaming audio pipeline. This streams audio using rtpbin (RTP+RTCP) over a WiFi connection, and uses NTP to synchronize clocks on all machines to better than 100 microseconds. There is one sender and two clients. The clients are connected to DACs and amplifiers and are built into a pair of loudspeakers, one into the left speaker and one into the right. The goal was to get synchronized streaming of PCM audio, with synchronization always better than 1 millisecond between left and right speakers. This helps to keep the stereo image centered. <o:p></o:p><o:p> </o:p>I have been able to achieve and better the 1msec synchrony goal, but careful listening reveals “ticks” or “pops” in the audio that happen relatively frequently and only when there is audio (never in the absence of music). I assume what is happening is that zeros are being inserted into the audio, and when they happen to coincide with a peak in the music signal the result is audible. <o:p></o:p><o:p> </o:p>In rtpbin, I have set the following parameters:<o:p></o:p>Latency=60 (milliseconds)<o:p></o:p>max-ts-offset-adjustment=2 (nanoseconds per frame???)<o:p></o:p>ntp-sync=true<o:p></o:p>ntp-time-source=ntp<o:p></o:p>rtcp-sync-interval=60000 (microseconds, or 1 minute)<o:p></o:p>all other ntpbin parameters are left at the default value.<o:p></o:p><o:p> </o:p>The pipeline ends at an alsasinnk. I set the properties:<o:p></o:p>drift-tolerance=500 (microseconds)<o:p></o:p>provide-clock=false<o:p></o:p><o:p> </o:p>I have been making measurements of the synchrony of the left and right speakers using ARTA and a microphone placed in front of each speaker. Measurements are done over long periods of time (e.g. hours) at regular intervals (a few minutes each). This data looks very good, and shows the level of synchrony I have been able to achieve. <o:p></o:p><o:p> </o:p>Unfortunately the measurements did not reveal what listening test did: pops and ticks in the audio. My guess is that this is due to the way that the pipeline audio data is being modified in response to ntp time data. <o:p></o:p><o:p> </o:p>Initially I had set the property max-ts-offset-adjustment to values in the thousands or hundreds (of nanoseconds). Measurements that were performed at intervals of only a few seconds would reveal the playback timing jumping around quite erratically and randomly as much as 10 milliseconds. This was surprising, because at the sampling rate I am using (48kHz) there are only about 50 frames per second. Until I set the max-ts-offset-adjustment parameter to 1 or 2 nsec could I prevent the playback timing from jumping around. I cannot set this parameter any lower. <o:p></o:p><o:p> </o:p>Visual inspection of the timing measurements showed the timing randomly advancing and retarding every few seconds. Over time the “by eye” average seemed to be about the expected average value. Perhaps there is too much jitter in the data and corrections are being wildly overdone? Even with the minimum amount of ts-adjustment per frame, the audio has regular pops. <o:p></o:p><o:p> </o:p>I am wondering if some kind of low-pass filtering could be applied to the timing info. The effect will be a smoothing of the data, so that the necessary correction changes smoothly over time instead of wildly back and forth. A parameter that conveys the maximum allowed or expected ts-rate-of-change could be introduced. From there it is straightforward to implement low pass filtering with a corner frequency corresponding to this time period using e.g. an FIR filter or moving average with a timing data sample rate equal to the rtcp-sync-interval. Higher frequency changes will be suppressed, but their values will still contribute to the overall ts correction if they contain a longer period drift. This would be much better than the current max-ts-offset-adjustment type limiting. <o:p></o:p><o:p> </o:p>Is it possible to implement filtering of timing info along these lines?<o:p></o:p><o:p> </o:p>I would be happy to provide my pipelines if that would be helpful, provide measurement data, or any other info that might lead to a solution. <o:p></o:p><o:p> </o:p>-Charlie<o:p></o:p><o:p> </o:p></div></body></html>