I was getting ready to create a new thread to talk about zone synchronization and discovered that it essentially started here and probably should continue here. I am also going to take some minor exception to some of the things posted here if only to clear some things up.
A bit about my background. I have been involved in data communications professionally for quite some time. Suffice it to say, if you use the Internet, you are using technology that I, in part, helped create. I also experiment with software-defined radio which, at some of the extreme cases I play with (software defined radio interferometry) the problems of synchronizing playback clocks seems moderately trivial.
In the case of a single streaming player, having the DAC clock control the transfer is necessary and sufficient. It works just peachy. You can have a relatively inexpensive local oscillator with low phase noise (results in low jitter) to provide clocking to the DAC and there will be few, if any, IM products produced by the phase modulation of the clock. The only problem is, once you have more than one oscillator, i.e. you have more than one zone, you end up with clock slip, as mentioned above.
I currently have 6 zones in my house. The difference in clock accuracy is readily apparent when I group overlapping zones. I get clock/buffer slip relatively often. It is annoying. I have been playing with RPi3-based devices from IQaudIO and they are especially bad. I suspect their âbadnessâ stems from using the RPis single clock which, I suspect, is not a nice integer multiple of 44.1kHz or 48kHz. Where I use DACs with better clocks, I see less problem. Do we use an isochronous source and keep everything in lock-step (the S/PDIF approach with a master word clock) or is there a way to preserve the natural asynchronous transfer but still lock the clocks in all the devices to central reference?
I have done both. Both work. It is possible to have a really good, low-phase-noise voltage-controlled local oscillator that is âsteeredâ by a phase-locked loop that locks to a master reference. AES/EBU, TOSlink, and S/PDIF support this and really good DACs extract the clock from the data stream and synchronize the local clock, but the controlled oscillator retains its low-phase noise quality. So it is possible to have slaved clock quality (phase noise and jittter) just as high as that of a free-running crystal oscillator.
Of course, we could just slave all the clocks to a single master source. GPS-disciplined clocks are pretty common and relatively cheap now. This seems (to me) to be the way to go for keeping things in sync. It shouldnât cost more than about $200 to add GPS-disciplining to the clocks in a DAC. (And one can get the frequency right by multiplying up from 1Hz rather than down from some higher frequency. (Every even-Hz frequency is an integer multiple of 1Hz.) GPS receivers with 1 pulse-per-second (PPS) are cheap (under $50 in unit quantities) and the circuitry needed to frequency lock the clocks to the 1PPS is relatively inexpensive too. Time to bug some DAC and/or S/PDIF streamer makers about this.
But there is one thing Roon could do to make the problem less noticeable. Basically you just need to insert a long enough gap between cuts to let the buffers run dry. It is a standard async resynchronization approach. (After all, what are stop-bits for?)
And maybe they have done it but I have missed it. Crossfade time maybe? But if it is crossfade time, a period of 1 second is unnecessarily long. Since Roon has the information about buffer size and sample rate, it can calculate the worst-case resync time, on the order of 25 ms for a 1kB buffer at 44.1kHz. I doubt a 25ms gap is going to be noticeable ⌠unless you are listening to something inherently gapless. (Abby Road anyone?) Even then it is probably better than the mis-synchronization continuing to drift farther out.
Other ideas about this?
