It’s an interesting idea, and I’m glad you brought it up.
First off, I don’t even know how something as difficult as the current tightness of synchronization is accomplished.
I’ve gone into a bunch of detail on that topic in this thread.
For one thing, I believe I observe - although I may well be fooling myself - that one of the playback areas doesn’t sound quite as good while synchronized as it does when playing the same tracks alone.
One of your zones is running bit-perfect. The others are making adjustments to conform to the clock of the perfect one. The differences should be subtle, but they are still there. The worst situation is when you have big discrepancies between the clock rates of various devices, so corrections become frequent enough to make a difference.
This is something I want to continue to improve. I think in the end, we’re going to end up moving some of the sync correction handling to the server so that we can do more expensive DSP to “hide” corrections, or otherwise control the process more tightly.
For another thing - I see that the audio streams sent to all zones are forced to conform to the needs of the least capable zones
1.3 will fix this for RAAT zones–the core will send different streams that have had different processing applied and synchronize them while taking into account the processing latency.
1.3 is also going to support a setting for choosing the clock master–so if you have a particular quality-critical zone, you can make sure it’s bit-perfect.
Other technologies (which, admittedly, have a whole lot less variation in capabilities) will continue with the current behavior, at least for the time being.
This is something that I really want to do, but it’s a huge amount of work to build it, then make it stable.
I think it could be done “tightly” for all of our current output mechanisms except for HQPlayer given sufficient effort. They all have (at least) a ms-resolution clock that we can use to line things up.
RAAT is actually in a worse situation than the others because USB devices often mis/under report their output delays.
1.3 will have a setting for micro-adjusting delays on RAAT endpoints, so if you really want to, you can record a synchronized start across a pair of devices (I like to make a stereo recording of an impulse signal, with the left channel from one device and the right channel from the other) and then adjust one to match the other.
Thinking about this from a product design standpoint–“loose” vs “tight” synchronization is not a nice distinction to explain to a less sophisticated user because the choice between “perfect in one way and imperfect in another” and “imperfect in one way and perfect in another” is an awkward one to offer, and because to anyone without the discipline to put their speakers far away from each other, the “loose” setting will feel like the “broken” setting.
I think if something like this came to be, we would do it like this: first, we’d support tight linking across all technologies that could do it. Then we’d make a setting like “move drift corrections to track boundaries”. That way, instead of a high-level choice of synchronization strategy, it would become a smaller choice, that really didn’t change things that much for anyone, but it would still create a pathway to the quality outcome you want.