RE: [chrony-users] Configuration examples and accuracy

["Charlie Laub" <charleslaub@xxxxxxxxxxxxx>]

Thank you for your questions.

The clients are audio endpoints. There is one client per speaker, and there
is a stereo pair of speakers. The audio chain starts at a third "source"
computer where audio is played/controlled, passes into the software
Gstreamer, is sent to the client computers over the LAN using RTP where it
is received and processed again using Gstreamer in order to perform DSP
(this implements the loudspeaker crossover filtering) and then is rendered
via an audio interface to amplifiers and the loudspeaker drivers. On the
clients, Gstreamer uses the RTP timestamps and the local disciplined clock
to regulate the playback rate. This helps to correct for dropped packets and
for differences in the playback rate of the DACs, which have their own
internal clocks that are independent of the system clock. There are
certainly lots of balls in the air with this setup, but I am building active
wireless loudspeakers with onboard self-contained amplification that use
home WiFi as a means to distribute the audio signal. This is about the best
way to do that as far as I know. This has been a DIY hobby effort of mine
for several years now.

Because of the particulars of the hearing process, the perception of the
stereo "image" is influenced by a delay in the playback of one loudspeaker
compared to the other one. A delay causes the apparent center of the sound
to shift away from that speaker towards the other one (the Precedence
effect). A delay of approximately 100 usec or more results in an image shift
that is noticeable. This is both the effect that I want to minimize or
eliminate, and a way to judge how well synchronized any two clients are at a
given time. I leave the loudspeakers on and playing music, and I
periodically sit down in the center at the listening position and try to
discern the extent or presence of the image shift. The current setup is
pretty good (but not perfect) when evaluated in this phenomenological way. 

To obtain more numerical information, I can perform a measurement using the
software ARTA and some data post-analysis. ARTA is a free audio measurement
software package. Using one mode of operation ARTA sends a pulse from the
source (computer) through WiFi to the client computers at the loudspeakers.
For the measurement I disconnect the loudspeakers and disable the crossover
software so that the pulse is simply rendered via the DAC to an analog
output on each client. Using a dual channel audio interface back at the
source computer (connected via some long cables) ARTA simultaneously records
the output pulse from the clients in an audio file, e.g. lasting a couple
hundred milliseconds. I can then process this file via some additional
software to identify the time when each pulse appears, the difference in
which is the relative delay between client systems. The resolution of this
measurements depends on the sample rate used to record the data, although
interpolate can be used to get sub-sample resolution. For example, a 96kHz
sampling rate gives about 10 usec resolution before interpolation. This
measures the synchronicity of the entire playback chain, not just of the
clients, but that is what I am interested in for my application. I do not
have or know of another way to make such a measurement on the clients
directly. 

I performed measurements of this kind in the past when I was attempting to
set up a system consisting of three Raspberry Pi 4 computers on an isolated
network without any time reference. I was experimenting to see what level of
synchrony could be obtained without an external reference. I used the method
explained above to record the relative delay of the clients every couple of
minutes. At that time I attempted to use many of chrony's features to
improve the synchronicity, but the result was not good enough and was
probably doomed by the lack of time reference within the system. I was
attempting to slave the two clients to the "sender" computer clock, which
was undisciplined. It didn't work well enough, but the WiFi performance of
the R-Pi SBCs is not great. I now use better computing hardware (Intel based
mini PCs) and WiFi and the local stratum 1 timeserver. All of these help
quite a bit. 

I will look into some of chrony's features and parameters (such as maxdelay
and xleave) and see how far the performance can be improved. I did look into
these kind of parameters in my earlier trials, so I am somewhat familiar
with them although it has been a year or two at this point. Thanks for the
example.

-Charlie


-----Original Message-----
From: Miroslav Lichvar <mlichvar@xxxxxxxxxx> 
Sent: Wednesday, January 26, 2022 4:55 AM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-users] Configuration examples and accuracy

On Tue, Jan 25, 2022 at 11:29:04AM -0500, Charlie Laub wrote:
> Hello Miroslav,
> 
> Thank you for creating and publishing this new page. The info is very 
> helpful and demonstrates the level of accuracy that can be achieved 
> under a variety of configurations. I have a local GPS PPS based (via 
> NTP running on an R-Pi) Stratum 1 server. The other machines on my 
> network all run chrony and reach tens of microseconds error, which is 
> OK but could be better. I need to synchronize them in order to 
> coordinate distributed audio playback, for which 1msec is too much 
> error between machines. But synchronicity better than 100 usec works 
> OK, with 10 usec being the ultimate goal. I will look at your examples 
> to see how I can improve the client performance, however, most 
> machines (not the stratum 1 server) are WiFi based so I doubt I can 
> improve them much more. My clients use a poll interval of 4 or 5 for the
GPS based local timeserver. No PTP or hardware timestamping is used.

Getting wireless clients within 10 microseconds is going to be very
difficult. The drivers don't even provide a software TX timestamp.

You could try a shorter polling interval combined with the maxdelay and
burst options. You would need to find the minimum peer delay for each device
at which it can get a good measurement frequently enough to keep the clock
in sync. This assumes the network is not loaded for longer periods of time.

For example:
server ntp.local minpoll 0 maxpoll 2 burst maxdelay 0.0012 xleave

How do you verify that the clients are in sync? I assume they work as
speakers. Is there a tool which can analyse recorded audio of multiple
speakers and tell you how well they agree with one another?

--
Miroslav Lichvar


-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.