That pause when you add a new zone to a Sonos group…

So I have a question for the gathered crew who look at tech things acting a certain way and try to figure out what’s going on.

When I add a zone to a group in the Sonos app, there’s no playback gap.

Same song, same source in Roon, there’s a gap. And, I think, there’s a new stream name / gobbledygook (eg, what was “roon4f45fe24d876dd876c986” is now “roonf876b76a87696ab875d96e” or whatever even though it’s the same song), but now (pace @Greg_Friedman @kitated @CrystalGipsy ) I now get grouped zones using Sonos native grouping. Which means, I think, that the pause is Roon saying “hey, I need to create a new stream to send to these new zones which might have different capabilities” which is generally polite and good behavior because a group of RAAT zones might have a different “least common denominator”. But with Sonos, it seems like you could offload all that “which zone can do what” to Sonos by just issuing the group command.

So my questions are:

  1. Does my theory hold water?
  2. Are there actually cases where when grouping Sonos zones you might want to change the stream that’s being sent to the group instead of continuing to send the stream as is and sending the Sonos “native group” command?

If the answer to 2 is “no”, then feels like it could be a good (albeit small audience) use case…

Here are a bunch of related threads with similar speculation just for good measure…

I can only add the following.
We sometimes have the problem that switching between ROON and SONOS (we use SONOS to play radio stations e.g. in the morning) does not work properly.
Then you have to actually dissolve the groups completely and then regroup them. Also the other way round - if a group was played with SONOS in the morning - ROON does not always manage to play all the players of the groups, they remain mute. You then have to dissolve the group and reassemble it.

Good morning, good afternoon, and good evening depending on your locale.

My abbreviated answer to both #1 and #2 is : “I don’t know”.

My longer answer is … “Hmmmm…”

I’ve played with the Sonos APIs a bit. Not enough to be expert - I was toying with the idea of a Roon extension which would detect when a Sonos zone started playback and could auto-switch an amp/receiver/streamer to that Sonos’ input.

I suspect that Roon integrates with the publicly documented Sonos API seen here:

If that’s the case, Roon is using a combination of control, cloud queue, and music APIs. I think what @Johnny_Ooooops is asking is “Can they be doing something better?” The only answer I have is “Maybe”.

To say anything more, I’d have to know exactly what Roon is doing and why they’re doing that versus something different. For example : when you add a zone using the Roon app, are they calling “createGroup” or “modifyGroupMembers”? Does their choice to call one or the other differ based on whether you are creating a group (going from 1 to 2 or more) or modifying an existing group (going from 2 or more to some other number)?

Then there’s the question of how they use the API to stream. It’s possible that each time they create or modify a group, they spin up a new queue/session/whatever. At a minimum, as @Johnny_Ooooops sees, and I do, too, they start a new stream.

@Johnny_Ooooops is wondering if they start a new stream because Roon settings can differ between zones. Possibly. I know you’ve played with setting max bits down to 16 for some zones. It’s possible that Roon goes with the lowest common denominator for your grouped zones. There’s also the question of DSP and who knows what else differing. In some cases, Roon may absolutely need to start a new stream to do what the user has implicitly asked it to do as a result of configuration.

Here’s where I’m going with this. This is complicated because the API options themselves are complicated as are the permutations of user settings in both Sonos and Roon and the capabilities of the zone players themselves. If I were writing the Roon code to control Sonos, I’d probably find one approach that worked and use it consistently. The more clever the code gets, the more bugs it’ll have. I’d stay simple. That might mean coding up grouping so that any time anyone manages a group, I just create a new group. Doesn’t matter what you’re going from or going to. Then playback would just play to that group. If you modify a group during playback, I’d stop playback, create a new group, start playback.

(At this point, if the person that wrote this code at Roon is reading this, they’re either saying “yeah…that’s about right” or “this guy is a moron”. Could be going either way).

My experience with Roon and Sonos is just ok. Group playback is just one issue. Volume control is the other issue and that got to a point where it was such a detractor from the experience that I actually chose to reduce my use of Sonos. RAAT devices just work so much better.

That said, I just tested grouping with my two “Roon Ready” KEF zones and there’s actually an even longer pause when grouping and ungrouping the KEFs than there is with Sonos. So if the goal here is gapless grouping, then moving away from Sonos isn’t your solution.

Was any of that interesting or helpful? :slight_smile: