Sometimes users have ungroupable zones but would still like to play the same playlist in each zone by setting up and starting play in each Zone as closely as possible, see this post:
Would it be possible to make such a “kludge” a bit better using the API to start play in a number of specified ungrouped zones at the same time ?
This is certainly technically possible, for some value of “the same time”. I am probably never going to have the time to spend making it, but all the pieces needed exist in the API.
I’m not sure why this would be a “project”. After all even zones that can natively be grouped are able to drift apart. This happens for me all the time because one zone has convolution applied and not the other.
So the argument about it not being native functionality due to synchronisation problems just doesn’t make sense.
Roon is unlikely to implement dissimilar zone groups because they avoid allocating scarce development resources on outcomes that don’t meet their standards. I think “Don’t be lame” is a powerful principle for them. It may not ensure lame outcomes never occur, but it does thin them out.
If you can break zone sync with convolution that is interesting and worth reporting in Support to see if it is a known issue. But it doesn’t bring dissimilar zone groups closer.
So I thought dissimilar zone groups might be implemented after a fashion in the Roon API and Ben thinks it possible. My non-existent Java skills don’t run that far so I opened this thread to run it up the flagpole and see who salutes.
If you don’t like the idea and prefer to wait for Roon to implement it, then I’ll delete the thread. Given that Roon would LOVE to do it (I’m serious, Brian would give his eye teeth for a robust way to do it) and they haven’t yet been able to devise a robust solution I would guess it will be a long wait.
Via the API you can certainly play the same track in as many zones as you like (send the same browse item action to different zone IDs), however there will be a certain amount of highly unpredictable latency between each load and play request being actioned - think time between pressing play and a track being loaded and played - it will be similar to that between each zone initiating playback.
Attempting to get better initial sync has some complications: there is no load track, just load and play it - ie just like clicking play on it in the UI. Once a track is loaded however, it could be paused, seek back to zero and play again in each zone - this will be better sync as the response time for play/pause is usually much quicker than browse item invocation, but there is still no guarantee of instant action - it will be highly dependent on the speed of your core, network, output device buffer pre-load size etc.
Also, if taking this latter approach of load+play, pause, seek, play, then the chance are that at least some initial sound of the track will be heard. Either way - quite ugly really.
Likewise there is no direct mechanism to load and play a track from a specific cue point. You can load and play it (single action), then seek (another action).
The API appears designed specifically to provide almost simplest possible transport and browse control behind a UI and so it just is not suitable for audibly simultaneous playback start.
I do wish Roon had an API that could load and play a track from a position as a single action and wish that it had a zone copy function rather than just transfer. I find myself wanting to copy what’s plying to another non grouped different tech zone more often even than transferring between zones.