Flexible Multi-Group Audio Zone Management

[Okosisi]

Related: to https://forum.wiimhome.com/threads/multiroom-api-limitations-and-feature-request.5967/ but it focused on platform.
Context and why: People want this but it's not easy to do ANYWHERE except on very expensive gear and even then. This would make WiiM Audio very sticky in multiple-zone situations
Prior art & acknowledgments: the latest firmware brings persistent groups. Very good! Suggests most of the code for this is in place. Hopefully the first steps can be low effort.

Details:
Background:WiiM's current implementation allows basic grouping of audio devices but lacks the ability to create and manage overlapping logical groups, limiting the system's flexibility for whole-home audio management.
Feature Description:
Implement a multi-group (optionally hierarchical) management system that allows:

• Amps & Audio devices to belong to multiple persistent logical groups simultaneously
• Priority-based stream management between overlapping groups
• Flexible grouping patterns (e.g., "Dining Areas", "Entertainment Spaces", "Whole House")
• Group-level stream conflict resolution ie if an amp belongs to two groups and they are being streamed to simultaneously which membership should it respect?

Benefits:

• More intuitive whole-home audio management
• Better support for different use cases (daily routines vs parties)
• Enhanced control over audio zones without requiring external automation platforms (most don't even support this or do it poorly).
• Improved family-friendly usage with priority settings

Here is a quick and dirty spec that should be almost complete. https://docs.google.com/document/d/1D-6vTC7kkjq1n-o3iRWb2uSpfxJXuEBaHCCBLHqfXmw/edit?usp=sharing
Feel free to reach out if WiiM wants to implement this. I have a system with 15 WiiM amps and am testing integrations all the time.

 

[slartibartfast]

Related: to https://forum.wiimhome.com/threads/multiroom-api-limitations-and-feature-request.5967/ but it focused on platform.
Context and why: People want this but it's not easy to do ANYWHERE except on very expensive gear and even then. This would make WiiM Audio very sticky in multiple-zone situations
Prior art & acknowledgments: the latest firmware brings persistent groups. Very good! Suggests most of the code for this is in place. Hopefully the first steps can be low effort.

Details:
Background:WiiM's current implementation allows basic grouping of audio devices but lacks the ability to create and manage overlapping logical groups, limiting the system's flexibility for whole-home audio management.
Feature Description:
Implement a multi-group (optionally hierarchical) management system that allows:

• Amps & Audio devices to belong to multiple persistent logical groups simultaneously
• Priority-based stream management between overlapping groups
• Flexible grouping patterns (e.g., "Dining Areas", "Entertainment Spaces", "Whole House")
• Group-level stream conflict resolution ie if an amp belongs to two groups and they are being streamed to simultaneously which membership should it respect?

Benefits:

• More intuitive whole-home audio management
• Better support for different use cases (daily routines vs parties)
• Enhanced control over audio zones without requiring external automation platforms (most don't even support this or do it poorly).
• Improved family-friendly usage with priority settings

Here is a quick and dirty spec that should be almost complete. https://docs.google.com/document/d/1D-6vTC7kkjq1n-o3iRWb2uSpfxJXuEBaHCCBLHqfXmw/edit?usp=sharing
Feel free to reach out if WiiM wants to implement this. I have a system with 15 WiiM amps and am testing integrations all the time.

LMS (Lyrion) can probably do this with the "Group Player" plugin installed. All WiiM players with Squeezelite are fully compatible with it.

 

[Burnside]

You can already define persistent groups whose members overlap and priority is already given to the most recent playback request. I could see issues though if the overlap was with the main device in the group as starting another group would then kill playback in the first.

 

[jeffme]

@Okosisi - thank you for your this suggestion & especially for taking the time to rough out a spec doc.

Is there a way of prioritizing what you're asking for? For example, I'd just like to be able to change an ad-hoc group in a way that removes the parent of the group. Or, I'd like to be able to directly select a persistent group for the now playing music that didn't include the parent of the now playing group (or the only member of that now playing group). I believe your spec would enable that, but your spec goes much further in its flexibility and configurability. I (and, of course, I believe most other people...) would be very happy to get the more pared-down feature set, the 80/20, without the additional hierarchies, etc.

I'm also a >10 WiiM system user and am currently spec'ing out a >20 WiiM system, so I can see the value of what you're suggesting.

Again, thanks for not just the suggestion, but the effort to put together a supporting doc. Way above and beyond!

 

[Okosisi]

Yeah I wrote the whole thing so engineers can see the end to end. But it can be piece-mealed for sure. I think the main thing is - allow multiple overlapping groups that are persistent. Figure out a way to deal with streaming conflicts within the overlapping groups. The rest are lower priorities.

I think the need for ad-hoc groups goes away to negligible once that is done and is easy to use.

From my understanding - what you suggest will not work. The parent of an ad-hoc group serves special functions within it. It becomes the parent, the main coordinator. Removing it will destroy any current stream. Don't quote me - just some interpolation from what I know about how it works.

 

[jeffme]

From my understanding - what you suggest will not work. The parent of an ad-hoc group serves special functions within it. It becomes the parent, the main coordinator. Removing it will destroy any current stream. Don't quote me - just some interpolation from what I know about how it works.

I'd be fine with an interrupted stream, as long as it allowed transfer. Seems like you could just store the state of the current stream (source, track, time) and transfer it if the original parent is destroyed. Seems like the tail is wagging the dog here. I was wondering if there might be some IP protection legally blocking implementation of such a feature.