They’re trivial if you’re thinking like an architect, starting from scratch and defining a full hardware/software stack with this problem at the center. Certainly, the concept isn’t hard.
In the world we live in, there are few limitations that are worth mentioning up front:
- Solutions that depend on a hardware PLL are impractical, since it’s very rare that we actually have the ability to make fine clock adjustments in software via audio drivers as they most commonly exist today.
- Depdending on awesome top-down ideas like the GPS clock are impractical, since we play music on hardware that comes from different manufacturers at different price points–all the way from mid-range Android phones up to a $100k+ dCS Vivaldi stack, and we must work with things already in the market.
- Doing accurate clock synchronization over WiFi networks can be difficult because WiFi hops sometimes impose unexpected asymmetrical delays on network traffic (i.e. delays that undermine 1/2 RTT reasoning). We are actively working on figuring out ways to mitigate this problem.
I agree, the underlying techniques: measuring clock drift and correcting for it, aren’t really that hard. In my experience, they are sometimes non-obvious to people who haven’t spent time thinking about the problem before, but that’s about it.
In any case, RAAT already measures and corrects for clock drift. This was designed in from the start, as it should have been.
Usually when we see clocks drifting audibly, it can be traced back to some networking detail–either WiFi or a managed switch–interfering with clock synchronization exchanges.
The way RAAT handles multi-zone playback/clock management is like this:
First, we elect one of the devices to be the “clock master”. That device drives the pace of the playback stream. We could just as easily use the computer’s system clock for this, but choosing a master from among the playback devices potentially gives us access to a better clock, and allows one of the zones to operate without performing corrections at all, which can be desirable for the “best” room in the house.
The “clock slave” devices receive the stream at rates that may mismatch their personal clock rates. They are responsible for periodically performing clock synchronization against the master device, modeling the master clock rate, and then applying corrections to compensate for the clock rate discrepancy–either by altering the stream in software/DSP, or by controlling a hardware PLL.
I am familiar with some commercial products that take this approach as an alternative to handling drift correction as a first class problem (as we have).
Clock rate discrepancies of 100ppm from one device to the next are not uncommon in our observations That means by the end of a 10 minute song, we’d see 60ms of drift–bad enough to be easily noticeable to a layman. Forget about listening to a full symphony or a concept album comfortably.
This is a band-aid that compromises quality. Not an option for us.
Your ideas so far have rested on an implicit assumption that we missed the important detail of “compensating for clock drift” when engineering RAAT. Since that is not the case, I think the next steps here are to do some troubleshooting and figure out what aspect of your environment is exacerbating the problem.
One of the tests we perform when certifying Roon Ready devices is to ensure that they can sustain grouped playback for 24hrs without drifting relative to other devices. This test is performed regularly enough over here that we’re confident that–in general–the drift correction mechanism is capable of working properly.
You might be running into an edge case, or a bug, or maybe your network is behaving in a way that we didn’t anticipate. I’d like us to get to the bottom of this regardless.
(cc @support)