Music Assistant
Sound card output as Player #3492
Replies: 8 comments 32 replies
|
+1! At the moment I'm running Home Assistant with a Docker Container which hosts 6 instances of MPD, which are then used in Home Assistant for Audio playback. However, MPD lacks volume normalization apart from replaygain (which does not work if you create custom playlists based on moods across artists and albums) and while it works fine with Home Assistant, HA does not show the media library at all. It's just limited to these entities and that's it. I have a USB 7.1 sound card attached and connected to a multi-zone audio amplifier. At the moment, I cannot use Music Assistant at all, because it does not support local sound devices from what I understand (at least the doc says it doesn't). I'm avoiding all these WIFI, cloud-based smart-speakers, because total local control and independence of cloud services is a MUST for me. |
|
Agreed .. just installed Music assistant to see i can't add my local usb audio card ... sad ... and even better can't even stream to a bluetooth device .. what a joke... uninstalling. |
|
While there is no local audio out support in the Builtin Provider, I believe you could workaround this by using Home Assistant player provider: Should work with USB Audio Device that supports USB Audio Class 2.0 pipeline, like example:
Another option to USB Audio Device that could technically provide the same function but would need other drivers and has not been tested are HiFiBerry's products like example "HiFiBerry DAC+ ADC PRO", "HiFiBerry DAC2 ADC PRO", or "HiFiBerry DAC+ ADC" (which as bonus using HiFiBerry can makes a whole Raspberry Pi based build an all-in-one package that could be aesthetically pleasing and almost have the clean look of a commercial appliance) While not recommended with Home Assistant as player provider should also be able to play through Home Assistant via ex. MPD add-on: |
|
FYI I see many issues with the HA MPD players |
|
I’m using the external Squeezelite add-on on HomeAssistant for this and have MusicAssistant connected to it and its “not great“™️. It’s the choice between high latency and broken audio (choose one or more). Since its also used to play the doorbell sound when someone presses the doorbell button, multi-second latency is not very satisfactory. The best settings for SqueezeLite integration I found are the following (for each instance of SqueezeLite):
Not using This gives about 1,8s delay – most of which appear to be coming from SqueezeLite (part might also be from SqueezeLite Music Assistant integration). Home Assistant and Music Assistant UI update almost immediately to show an “Announcement” when pressing the doorbell button. Using SqueezeLite ALSA is compare but even harder to get to work. Native SqueezeLite PulseAudio has at least 1s more latency (if you look at its logs it appears to just hang for about 1s on every change) and also messes up sampling rates and volume during this time (previous playback continues using new sampling rate and volume). Getting ALSA with direct hardware access to work is not possible in my setup since I need channel splitting. (Left and right speakers are in different rooms.) (Guess I should make this into a blog post…) |
|
I remember we used to have the capability to use to local 3.5mm jack of the Homeassistant machine (in the first music assistant I think?). I would need to check, but from what I’m reading, I find it baffling that the solution still seems to be slimproto or some other workaround, instead of using the native HA audio container and pulse audio. I solved this by making a squeezelite amp from an esp32 and a dac, but I think an option to just plug something into the jack that you already have, instead of messing around with workarounds and other addons, or buying different speakers, would be very welcome (and dare I say a basic expectation). However I understand that this is an open source project. |
|
ho, just found this project and have casatunes music server (x86 windows based), i am thinking of nuking it, putting linux+alsa on it questions if you don't mind helping?
or do you issues apply to just basic single zone running on home assistant hardware? |
|
I haven't heard of anyone trying to do what you suggest. You would just have to try it. As for why Squeezelite...It is available as an addon and so is an easy way to get local playback working for HA users. Sendspin is only brand new so that why that isnt mentioned. |
ok, got it, sounds like there is nothing inhrently wrong with my mental model beyond can i wire it all together, just got music playing on my sonos, web and phone - gotta say, impressive project, thanks to you and the other contributors and i am not hearing any pros/cons that would direct me one way or another on clients - so i will try one or more of each and report back :-) i will have 8 zones on this box (each as a player and severla grouped for things like upstairs, downstairs, whole house) |
|
You can get some pros and cons by referring to these links |
|
@alphasixtyfive hi there fellow CT user, i am considering nuking the CT install and just installing linux and testing sqeezelite / sendspin / snapcast - did you ever try that? If not i feel an xmas project coming on....... |
|
@alphasixtyfive take a look...... https://gist.github.com/scyto/2eef6306f3ac0e90252d21b35c0e6473 let me know what you think note the note at the top of the page, but i am declaring this mostly a success |
|
ok, tested, have 8 streams, right room names, eveything syncs (i have no idea how) ocaasionaly some weird issues with the 'whole house' squeezelite group player - was finding i had to mess with each rooms volume after boot of the no-CT end points - but seems to be ok now 
for me the gist is functionally complete as i have a working system, don't believe i have missed any steps, but until someone else trys it we wont know.... |
|
to be clear, it would still be kinda awesome if music assistant could have had done all the messing around with soundcards and mixers for me, but it 100% isn't as simple as just a flag to output to |
|
only issues i have found so far:
|
|
I have now switched to (and contributed to) this, its a perfect solution for existing casatunes hardware (only need to install very plain and minimal debian and docker, i plan to add 12v trigger functions for each zone in a future feature. https://github.com/chrisuthe/Multi-SendSpin-Player-Container development is active, the upcoming version 4.0 will be the one you want to use, we have discussions on features and function on the MA discord |
|
Local audio out has been added to 2.9.0 beta 4 |
|
The apparmor profile (music_assistant_beta/apparmor.txt) actually is pretty wide open already — it starts with bare capability,, file,, and signal, rules with no path/argument restrictions, which in AppArmor-speak means unrestricted access across pretty much everything the container can see. So I'm not sure apparmor paths are actually the bottleneck here, since it'd already be broader than any hand-added /proc/asound rule. What I did notice: config.yaml sets audio: true but not udev: true, and there's no explicit devices: mapping. My guess (could be wrong!) is that audio: true gets you PulseAudio-proxy access, which is fine for playback through HA's own audio pipeline, but proper hardware enumeration (card names, aplay -l-style discovery, hotplug) tends to lean on udev metadata rather than just the raw device node. I peeked at Supervisor's source to double check, and udev: true really only does one small thing — a read-only bind mount of /run/udev (docker/app.py, MOUNT_UDEV in docker/const.py). No new capabilities, nothing writable, doesn't touch apparmor — so it seemed like a pretty low-risk thing to try. For what it's worth, this is basically what @scyto ended up doing for Multi-SendSpin-Player-Container's addon — udev: true + usb: true + an explicit devices: ["/dev/snd:/dev/snd", "/proc/asound:/host/asound:ro"] mapping alongside the apparmor rules. Might be worth trying the same udev: true addition on music_assistant/config.yaml / music_assistant_beta/config.yaml before reaching for more apparmor changes — happy to open a PR if that sounds like a reasonable direction! |
|
@chrisuthe yes that PR sounds like exactly what we need. (sorry for the delayed response! was away for a bit) |
|
update: Root cause turned out to be something else. I tried the udev: true fix on a manual test container (bypassing Supervisor), also unmasked /proc/asound and bypassed Supervisor's PulseAudio-routing asound.conf. None of it worked. calling snd_card_next() directly via ctypes returned nothing. Dug further and found open("/dev/snd/controlC0") was failing with EPERM, even though the node showed up fine in ls. Turned out to be Docker's device cgroup allowlist. Mounting /dev/snd just makes the nodes visible, it doesn't actually grant permission to open them. We need an explicit --device /dev/snd flag for that. Added that and devices enumerated right away. So the missing piece looks like devices: [] in the add-on manifest, not udev. MRA's manifest has devices: ["/dev/snd", ...] explicitly listed, which seems to confirm this. |
|
...and one more update (sorry for the noise, really want this working...) It's not great news. I tried making the MASS manifest exactly to MRA's working config (udev, usb, uart, apparmor, devices: [/dev/snd, /proc/asound]). Confirmed via docker inspect that the resulting cgroup rules are now identical between the two add-ons. /dev/snd enumerates fine. /proc/asound still comes back "No such file or directory" inside the container, and PortAudio still finds zero devices. /proc/asound is in Docker's default masked-paths list, and unmasking it requires --security-opt systempaths=unconfined at the container level. None of Supervisor's add-on manifest fields (devices, udev, usb, apparmor) touch that setting. I only got it working earlier by bypassing Supervisor and running the container manually with that flag. So this looks like it's not fixable from either app's manifest. It's a gap in what Supervisor's add-on model can grant. Might need a Supervisor-level change, not a home-assistant-addon one. Any other ideas? |
|
Okay, finally some real progress. Ran a clean test: stripped out everything from before (udev, usb, uart, devices, the security-opt flag) and ran 2.10.0b11 with just the stock audio: true mounts, nothing extra. It found all my devices. So the device access stuff earlier in this thread was real, but it only mattered for the ALSA/PortAudio fallback in 2.9.10. The PulseAudio backend in beta doesn't need any manifest changes at all. No config.yaml edits needed. This was all just me jumping the gun being too excited about this new functionality and not really digging into what was really going on in alpha labeled code. Sorry if I wasted anyones time. I'm really looking forward to 2.10 release :-) thanks to all contributors! |
|
Hey @alphasixtyfive and others - had some discussion internally with the sendspin and MA team at ohf about this and I want to urge us to go in another direction. Right now I think we should pull the local audio out plugin from MA completely, and rely on either a CLI player installed locally or a docker container or HAOS add-on to expose local audio as a sendspin player. This means the hardware handling aspects are kept out of Music Assistant so it stays as agnostic as it can be about what you're running it on. We've got the multi-sendspin container and HAOS add on that I put a good bit of effort into (Shoutout @scyto as well) that is in use at a good number of places, as well as an upcoming sendspin-CPP cli that mirrors the usefulness of the squeezelite CLI. The plan is to make a SUPER basic HAOS plugin out of that as well, so folks that just want local audio out can use that without any extra work, but the code stays out of the server. Taking thoughts and opinions for and against of course, but I think this is a safer way forward.. |
|
We don't want you to create a CLI for each one either @alphasixtyfive - You can check out https://github.com/chrisuthe/Multi-SendSpin-Player-Container for now, but the plan is to take the CPP work and create something similar that creates and manages those instances for you so MA just sees the players but you have the same control. Same end goal of the local audio out, no hardware interaction in MA core. |
|
I was previously using the Multi Room Audio Container app (it worked perfectly) but I moved to local audio because I thought it was architecturally more "pure" and direct. Now I am realizing that LocalAudio still uses sendspin so architecturally it's the same path. Is that correct? If so I don't really care where the connection to my local DACs happens. |
|
@mjmeno LocalAudio uses sendspin bridge to create sendspin player for every 2 channel device. For 6 or 8 channel multichannel devices it creates a stereo pair player for each channel pair and a multichannel stereo player which outputs the same stereo to each stereo pair output. Possibly in the future there will be a surround sound multichannel player for multichannel devices as well. |
|
Aren’t you already “keeping the hardware handling out of MA” by delegating it to PulseAudio? Sure, @mjmeno tryed direct hardware access (which didn’t go all that well…) but the primary use-case for “Local Audio-Out” as I understand it is taking to the HA audio container and having it handle the hardware interacting internally. It’s just that its protocol happens to be |
|
Recapping/clarifying my perspective which can hopefully be confirmed by a dev: Originally I felt that because all my DACs were connected to my MA machine it was odd to go out via SendSpin to the Multi Room Audio Controller running on the very same machine. Felt more natural to keep it all PulseAudio. When I actually got Local Audio working (via the MA 2.10 beta) I saw that SendSpin was still required (I realize now SendSpin seems core to all things MA). That prompted the comment in my previous post that it feels like architecturally the same path whether I do Multi Room Audio Controller or Local Audio. |
|
@chrisuthe I spent the day testing the addon and the local audio provider and worked with Claude to develop an edited short list of issues and items for possible discussion. These observations and comparisons are based on the main branch of the multiplayer addon and the current UX
Non-UX
Summary — MA integration/UX, for someone not deep in Linux audio:
Summary — where the addon may suit a power user better: The addon gives more direct visibility and control if you're willing to use it: richer per-player telemetry, a working static delay control already in place, and a standalone REST-controllable service usable independent of MA/HA. Running one process per output is also a simpler mental model to debug in isolation — one player, one log — versus tracing behavior through a shared graph and MA's own abstraction layers. Thanks. |
Uh oh!
There was an error while loading. Please reload this page.
It would be fantastic to have the ability to specify a local soundcard as an audio output for a player. This feature would effectively turn Music Assistant into a full-fledged open-source wired multi-room audio system.
To elaborate, I have a multi-room audio player from a company called CasaTunes, which is essentially a low-spec PC with two physical soundcards. Each output of these soundcards represents a zone (or room) and acts as an independent player. There are other companies employing the same approach while charging unreasonably high prices for it.
The idea of implementing local players would simply require the ability to specify the device and subdevice, for example:
-a hw:1,0This enhancement would open up new possibilities for multi-room audio setups using wired connections, adding tremendous flexibility for users.
All reactions