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: https://developer.sonos.com/reference/
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?