Balena Sound Multiroom - multiple airplay inputs routed to different sets of speakers

I’m a n00b to Balena and Raspberry Pi, and I’ve been educating myself to find the right architecture to do multiroom audio that can handle two airplay inputs at the same time, and route them to different subsets of speaker outputs. For example, I’d like to:

  1. Set up four rooms with a Pi and pair of speakers in each room (rooms A, B, C and D)
  2. Send music from airplay source 1 to rooms A and B, and at the same time send airplay source 2 to rooms C and D.
  3. No mixing of sources 1 and 2 will be done, so each of the four rooms can have one and only one source sent to it at a time.
  4. Change the routing of audio sources to the rooms on-the-fly, via web browser or iOS app.

Can Balena do this? All the examples of multiroom audio that I’ve read about or seen in videos send one music source to one or all sets of speakers.

If Balena’s not a great choice for this kind of setup, what might be?

Cheers, and thanks, in advance!

Theo

Hi, welcome to the forums.

Based on your question, it seems you can do with 2 different multiroom room setup instead of one which handles multiple sources. Setting up 2 multiroom balenaSound one for rooms A, B and another for rooms C,D can be a solution. You can set source independently for each of the setup. To learn more on how to setup multiroom please visit the blog or checkout the docs

Regards,
Amit

Theo,

Unfortunately the way that balenaSound does the multiroom functionality means that any balenaSound device on your network will find every other balenaSound device. Under the hood it’s using cote.js which uses mDNS for nodes to find each other.

However, you could experiment with the cote.js COTE_ENV variable:

If you set this as a device variable I think you will be able to put two devices into one environment (effectively room) and the others into a different environment. Then, when you play source 1 to environment 1, it won’t cross over to the other devices.

I don’t currently have a multi-room setup I can experiment with - so give it a whirl and let us know if it works.

Phil

Amit and Phil - thank you for your input. For Amit’s sake - I think I might not have stated clearly that I want to have the flexibility to route the two audio sources to different combinations of speakers at the click of a button on a browser. As in:

I start out with:
Airplay 1 → Speakers A and B
Airplay 2 → Speakers C and D

Then after a few minutes, I decide that I want:
Airplay1 → Speakers A C and D
Airplay2 → Speakers B

And then, a little later, I want:
Airplay1 → Speakers A, B, C and D
Airplay2 → none

etc.

So, Amit, your scenario sounds like a permanent mapping of a source to A & B and another source to C & D. Could this configuration be changed, at the touch of a button (or an API call, or whatever) to the configurations I just listed? Would it take updating some config files and restarting affected Pis?

From what Phil writes, it sounds like all Balena devices on my network will know about each other.

For both of you (and anyone else): would I be correct in assuming that Balena sound is designed to send the source to all connected clients at all times? In a slightly different scenario, if I only had one source and want to send it to a subset of all connected clients, is that possible?

Thanks, all!

While we haven’t tested this, what Phil said should be able to be set programmatically on your end by changing the COTE_ENV for each device. If setting this via a Environment Variable works as Phil suggested you try, you would be able within your code to call to the balenaCloud API to change that environment variable (Resources - Balena Documentation) on a device or list of devices. For example, you’d set COTE_ENV=airplay1 on the Raspberry Pis connected to Speakers A and B, and set COTE_ENV=airplay2 to Speakers C and D. When you want to switch it up, just change which device(s) have which COTE_ENV assigned to them. You’re correct that the assumption we have is that all speakers have the same source at all times, but due to this function of the underlying library, you should be able to set it up the way you’re describing. Making these env var changes will restart the container automatically (assuming the device is online), but do not require a full device reboot.