Is there room in Roon for an additional, "looser" synchronization flavor?

Feedback Feature Suggestions
1

If there’s to be just one flavor of synchronizing play to multiple zones, clearly the current flavor - where zones are kept synchronized tightly enough that even if they’re within earshot of one another, the timing of play from the different sets of speakers isn’t noticeably different - is the desirable one to have.

I’d like to argue, though, for the addition of a second flavor we could choose when appropriate.

First off, I don’t even know how something as difficult as the current tightness of synchronization is accomplished. It seems implausible to be able to synchronize the rates at which audio is being played to multiple zones, each of which is convinced it’s providing the master clock for playback. How can one control the playback speed of a zone whose USB DAC is controlling the speed at which it’s consuming data? Nonetheless, it’s being done and it works. Synchronization is subjectively nice and tight. Are interpolated extra samples sent to the faster-running devices? I have no idea.

Nonetheless… tight synchronization imposes a few limitations. 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. 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: for instance, if I group together several zones capable of playback of sampling rates up to 192kHz and one zone limited to 96kHz, then play some 192kHz audio, the audio is downsampled to 96kHz for all zones. Oh, and I’ve noticed that if I send MQA-encoded audio to a synchronization group including an MQA-capable DAC, that DAC tends to pop in and out of MQA-recognition lock (while MQA lock is stable if I’m playing to that DAC unsynchronized with others). And also it’s not currently possible to combine devices running unlike protocols (say, Roon and Squeezebox) in a synchronization group - which seems totally fair for tight synchronization.

I would find it really handy if I could group zones which are far enough apart to be out of earshot of each other in a looser way, just so I could give them a common playlist to play (instead of some kludgey annoyance involving queue transfers then manually restarting whichever player(s) got paused by that transfer). All I’d want would be for the different zones to be playing from the same queue, which I could modify at will, but I wouldn’t care if they were really synchronized - the only synchronization I’d think necessary would be, say, pulling them back approximately into line by delaying the faster devices whenever there was a break between tracks.

What I’d hope to gain from this looser synchronization (or pick a whole different name other than synchronization if you want) would be for all zones to play at their own optimal speed and sampling rate - as uncompromised as if they were playing alone - and if practical for these looser groupings to also be able to include devices running unlike protocols.

2

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.

4 Likes
3

I apologize for not having replied to this in a timely fashion, but I really have nothing substantive to add - I just want to thank you for having taken my request seriously and given a thoughtful reply, and commend you for (as I’ve now learned to expect when dealing with Roon) having apparently already been thinking about the issues I raised.

And of course the way you’ve come up with to explain what I called “looser” versus “tighter” synchronization to users seems far more easily understood than what I came up with.