First of all, this ecosystem is awesome! The fact I can configure my Raspberry Pi remotely, use a git push and deploy the services I want is an awesome experience. I’m super satisfied .
I’m about to sail on the adventure of designing my dream sound system. I’m using balena-sound as a starting point, and I have a few hardware / firmware related tweaks I’d like to set. Planning how to deploy these changes made me a bit confused about the multi containers paradigm.
What’s bothering me is that I want multiple services / containers to access the hardware, and ideally, all of these services should have the same sound related settings, including running the same amixer commands.
On the balena-sound project, the bluetooth-audio, upnp, airplay and spotify are separate services, and they all share eventually the same hardware, but run in different containers. What happens if during a spotify song, someone connects to the device via bluetooth? How would the spotify service know it needs to stop?
Say I have some firmware files I’d like to install on my system (I need these files). Additionally, I want to run a certain amixer command on startup. I tend to think, contrary to the balena-sound project that it’d be best to define a single container for all processes that use the sound hardware. Is it a bad beginner’s choice?
So to answer one of your questions directly: What happens if during a spotify song, someone connects to the device via bluetooth? How would the spotify service know it needs to stop?
The answer is they won’t and they don’t. If you play something using spotify and then also connect to the balenaSound device via bluetooth and play something else, both of those audio sources will compete for the device’s hardware. What you’ll probably find is that both the sources will stutter and mix together.
And then rather than answer the other questions, I would strongly suggest you watch the balenaSound project closely (repo here ) because a new version is about to be released and is undergoing some final testing. This is a ground-up re-write of the project using PulseAudio which moves things along rather dramatically. You can sneak a look at the code here: https://github.com/balenalabs/balena-sound/tree/balenaSound-v3.0
And if you have any more questions, get back in contact, and I can bug the maintainer and answer your actual questions.
@phil-d-wilson, thank you for letting me know about the v3.0 branch Using pulseaudio seems like a natural choice for this project, and I’m glad you’ve made progress on this! I also read ARCHITECTURE.md and I’m impressed by the design. Well done!
For anyone else encountering this thread in the future, I’ll note here exactly what firmware changes I would like to perform, and which I’m planning to perform upon each container, using this /lib/firmware mount advise.
Bluetooth
I’d like to test an expirmental solution for the notorious bluetooth jitters Raspberry Pi 3 issues, by using this fix, by the Arch Wiki for ARM. Naturally, I plan to do this firmware change on the bluetooth container only.
Pulseaudio / Sound devices
In the v3.0 branch, there’s only 1 container that actually accesses the sound devices, and this device will run the amixer commands I need. Additionally, this container needs some more firmware files for my hardware. So these firmware files will be installed on this container only.
To summarize, what made no sense to me in the previous design, was that many containers should need the same firmware related changes to be run, and making them all perform the same actions feels wrong. Only the v3.0 design allows one to not duplicate the firmware changes code, at least it should - I haven’t done all I wrote.
Glad to know you are liking the new design! One of the main motivations behind this major change in balenaSound was to find a solution to the exact problems you are describing, using PulseAudio also gave us a ton of benefits so a win-win!
Regarding the firmware changes you want to perform, a few comments based on my experience:
bluetooth: unfortunately I think the bluetooth firmware change that the Arch Wiki describes is already implemented in balenaOS at the host level (unless I’m misreading this). You can see the params in this two firmware files: /lib/firmware/brcm/brcmfmac43455-sdio.txt and /lib/firmware/brcm/brcmfmac43430-sdio.txt. I don’t think adding it to the bluetooth (or any) container will do any difference as the underlying hardware should already be properly configured, though please let me know of your results regardless!
Piano DAC: Have you tried using dtoverlays? I don’t think I’ve seen this particular DAC used before with balenaSound, but it should be pretty straightforward to setup. We have a quick guide for setting up DACs: https://sound.balenalabs.io/docs/dac-configuration. I did a quick google search and allo-piano-dac-plus-pcm512x-audio looks like the dtoverlay value to use. Ofc this might not work, but worth a try! If you are using balenaSound 3.x you can omit the step that sets audio=off.
In any case, interested in hearing back from your changes and experience with balenaSound!
It is straight forward, and I already get sound out of my DAC, but there’s a subtlety, explained here. In short, there is a certain operation mode or two available for the DAC, that it’s possible to reach only with these firmware files installed. I witnessed this back at the time I used moodeaudio. I also know I should run a certain amixer command.
Awesome :], I have little time to deal with my Raspberry as of now, unfortunately :/, but I’ll do anything necessary when time permits, to get my absolutely declarative and totally reproducible sound system. Hopefully, the balenaSound project will benefit from my testings, and contributions if any will be needed! Cheers .
P.S (edit): I think the balenaSound project can’t distribute the piano firmware files I mentioned, since their license won’t permit it.
.
Using pulseaudio seems like a natural choice for this project, and I’m glad you’ve made progress on this! I also read 
One of the main motivations behind this major change in balenaSound was to find a solution to the exact problems you are describing, using PulseAudio also gave us a ton of benefits so a win-win!
.
.