Balena Sound disable discoverability

Hi there,

I am running 4 Pi’s with balenaSound in multiroom configuration. 1 Pi3 and 3 Pi2B’s. So far this works good, but I noticed that I best use the Pi3 as master for the multiroom (I suspect the hardware specs help :wink: ), Now I am wondering, is it possible to make the Bluetooth, spotify and airplay services “hidden” without removing them entirely, to prevent confusion in which device to stream to?

Kind regards,

Hey there! Thanks for sharing your use case and the feature request. I’d be interesting to extend balenaSound with a CLIENT_ONLY environment variable that, when set, disables non-required services and prevents bluetooth from going into discoverable mode.

Are you up for contributing this to the project yourself? Every contain is defined as a directory here:, and each container has a script (i.e. You can check for the existence of such variable at runtime, and early-terminate the unnecessary services if so.

What do you think?

I can certainly give it a shot!

I’ll look into it and post back when I have results or questions!

Hi @jviotti, Okay. Since I’m not entirely sure of myself in what I am doing xD

Wouldn’t it work to replace the service startup line of the script with:

i f [[ ! $CLIENT_ONLY == “1” ]]; then
==insert startup line here==

in the services that are not required for a client only function? (If I am not mistaken, the fleet_supervisor and snapcast_client services are needed, the rest can be disabled?)

So, in the spotify_client it would be:

if [[ ! $CLIENT_ONLY == "1" ]]; then
  printf "Device is discoverable as \"%s\"\n" "$BLUETOOTH_DEVICE_NAME"
  exec /usr/bin/bluealsa-aplay --pcm-buffer-time=1000000 00:00:00:00:00:00

Would this create the CLIENT_ONLY variable and disable the services not needed from starting?

Hello, balenaSound maintainer here. You are on the right track, though i’d like to make some minor observations.

A client only device would indeed only need fleet-supervisor and snapcast-client services. Your approach is correct though I would frame it the other way around: if CLIENT_ONLY is defined then exit the script/container. You can see an implementation of this behaviour here:

Also, it’s a good idea to exit “early”, specially for bluetooth-audio container because it spins multiple processes. So in that case I’d move the “exit” logic to the top of the script.

Lastly, we need to consider that multi-room can be disabled. We don’t want to end up in a situation where multi-room is disabled and device is in client only mode, so basically all of our services will be dead :slight_smile: So there needs to be a check or warning in place.

Thank you for the info! That also answers another question I had too xD

No problem! Feel free to open a PR on the repo even if it’s a work in progress. It’s a lot easier for us to provide feedback in GitHub than through the forums. Also, thanks for giving this a shot!

Of course! Teaches me a few things at the same time :wink:

I’ll see if I can get GitHub to work with me xD I am new in how that works, but I’ll figure it out :slight_smile:

It can be tricky for sure! Before submitting check our contribution guidelines here:

TLDR: Be sure to include Change-type: minor on your commit message!

I opened a PR with the initial changes. I hope I did it right :laughing:

Thanks for contributing to the project!

Update: Changes have been made, and they have been merged :smiley:

Thanks very much for your contribution!