Audio stopped working on the host system

[frkos]

Hello @pvizeli After the latest release #9 audio on my host system stopped working. Looks like hassio audio locked it... Wben I run aplay I see this error: aplay: main:828: audio open error: Device or resource busy So I had to rollback to the version 8: ha audio update --version 8 and it works again

[felixsanz]

Home Assistant is designed as an appliance, it assumes it has the whole system to its own. If you want full control, use Home Assistant Core.

who assumes that? you?

[frenck]

The project does, @felixsanz. I sense a lot of frustration on your end, and not sure why that comment was personal towards me. I found it a bit offending, to be honest (most likely to caused by your previous choice of words, so that might be wrong interpreted from my end now).

Again, if you like to use your system for multiple things, please use Home Assistant Core, or use a Hypervisor to isolate.

[deftdawg]

It seems like the best course of action is to put some warnings on the project page or in the documentation and then close this as "Won't Fix", as the scenario where it occurs is usage that is "out of spec".

Unless there's some consideration underway to making this add-on an optional install or something.

[frenck]

The documentation and clear project scopes is something that definitely needs addressing, as has been mentioned in this blog post:

https://www.home-assistant.io/blog/2020/05/09/deprecating-home-assistant-supervised-on-generic-linux/

Currently, I'm working on a full spec together with some others. Once that has been done and approved it will be published.

Depending on that result, this will either be addressed or closed. However, at this point, the stanza for Home Assistant is still a dedicated appliance/hub.

[felixsanz]

The project does, @felixsanz. I sense a lot of frustration on your end, and not sure why that comment was personal towards me. I found it a bit offending, to be honest (most likely to caused by your previous choice of words, so that might be wrong interpreted from my end now).

Again, if you like to use your system for multiple things, please use Home Assistant Core, or use a Hypervisor to isolate.

obviously, i've been without sound on my main PC for 3 months and i've wasted more than 30 hours trying to debug everything, including downgrades of several packages like udev, kernels, etc, because i did not know that this container was messing up my system out of docker, of course that i'm mad and frustrated. this should be advised somewhere. you can't take system audio and don't even mention it on the website

docker is ISOLATION. you want us to respect the philosophy of HA, but you don't respect the one from docker? a container is a container. i've never seen ship containers driving the ship to the nearest iceberg

[frenck]

docker is ISOLATION. you want us to respect the philosophy of HA, but you don't respect the one from docker? a container is a container. i've never seen ship containers driving the ship to the nearest iceberg

I think you are mixing up 2 different things here @felixsanz. If you want to run Home Assistant on Docker, we provide Docker images: Home Assistant Core.

The solution you are using is an appliance that leverages Docker, but is not bound by it. It is just one of the pieces the appliance uses. For example, it communicates and manages the host system as well, via D-Bus.

[patmann03]

@felixsanz install this addon. It resolves it.

https://github.com/OPHoperHPO/hassio-addons

[frenck]

It provides a dummy audio output in those cases, to ensure an audio device can be expected.

[bilak]

well well, after 3 weeks trying to solve problem with QNAP I've found this. It really should be optional to run hassio_audio container.

[chozandrias76]

@felixsanz install this addon. It resolves it.

https://github.com/OPHoperHPO/hassio-addons

I tried installing your addon through Home Assistant and it failed. I couldn't find the logs that said why, but I was following my guide here: https://community.matrix.one/t/home-assistant-zigbee-integration-with-matrix-creator/3003

[OPHoperHPO]

@chozandrias76 I updated the add-on to version 3.1, try updating the information about the add-ons and installing it again.

@felixsanz install this addon. It resolves it. https://github.com/OPHoperHPO/hassio-addons

I tried installing your addon through Home Assistant and it failed. I couldn't find the logs that said why, but I was following my guide here: https://community.matrix.one/t/home-assistant-zigbee-integration-with-matrix-creator/3003

[frenck]

ADR-0014: Installation method: Home Assistant Supervised

Has been finalized, approved and instated. It defines what is supported and what not, in this case, for running Home Assistant Supervised.

https://github.com/home-assistant/architecture/blob/master/adr/0014-home-assistant-supervised.md

More about what a supported installation method is:

https://github.com/home-assistant/architecture/blob/master/adr/0012-define-supported-installation-method.md

ADR-0014 states:

• The operating system is dedicated to running Home Assistant Supervised.
• No additional software, outside of the Home Assistant ecosystem, is installed.

This means this issue describes a use case that is not supported. Nevertheless, we are open for contributions that improve compatibility with a community-supported method like described in ADR-0012.

Closing this issue as a result of the above.

[jendib]

I wasted way too much time on this, thanks for reporting this bug. It's still beyond me how a Docker container breaking the audio of the host is considered normal behavior, but the fix addon from @OPHoperHPO is working nicely.

[dimovnike]

looks like @OPHoperHPO fix stopped working... but @Daenara trick (with tagging) is working.

[jendib]

OPHoperHPO apparently fixed its addon and it's fine on my side at least (I can see that the module is loaded in logs).

[OPHoperHPO]

looks like @OPHoperHPO fix stopped working... but @Daenara trick (with tagging) is working.

Open a new issue in the repository with the addon by attaching the addon's log there, also write the version of the addon that you use on your system, the hassio version and the hassio_audio container version.

[GazAt105]

@OPHoperHPO fix is not working for me and I have raised an issue in the repository covering same. @Daenara trick is working for me.

[GazAt105]

I spoke to soon. HA has pulled another version and now it is back to running pulseaudio and blocking access to other apps.

[GazAt105]

I was wrong, @OPHoperHPO addon is working ok, I just didn't know it.

[jmtatsch]

Months without audio on linux are finally over. Thank you @OPHoperHPO

[ORi0N]

Thank you, thank you, thank you @OPHoperHPO for that addon fix. I have spent the last 4 days testing different pulseaudio configuration in order to resolve this problem. Only to discover that the s6-supervise kept re-starting the pulseaudio in system mode, that takes control over the audio. I only found this article after having read the following: https://askubuntu.com/questions/1279000/how-can-i-disable-pulseaudio-system-mode-and-use-the-normal-systemd-per-user-ser Which finally gave me the clue that it's HA doing this :s

I must add I don't understand at all why a docker container should grant the sole access over the host audio. Isn't like isolation like the whole part of containerization ? Please make it a setting so other new users like me don't lose 4 days over something trivial as this.

So again, thank you @OPHoperHPO for your fix.

[jbirdjavi]

I agree in not understanding the decision. The only answer that we've been given is that Supervised Home Assistant is designed to be the only thing running on a given machine. But that doesn't really answer the question of why this specific decision needed to be made. My guess is that they don't want people to run the supervised version anymore so making it harder for people to use is a good thing in their eyes. I'm grateful for the work that they do, but I just don't understand this one at all.

[ORi0N]

I'm in the process of migrating from OpenHAB. And my docker host is running multiple other containers with 'home automation' services like OpenHABv2, OpenHABv3, zoneminder, snapcast, opentherm gateway, nginx... But as soon as I start the HA container all other services lose access to audio. No more multi room audio (snapcast), no more OpenHAB where still 90% of my code resides as I'm hesitant to migrate when the audio is this unstable. Etc, etc ...

Dockers philosophy is a sound one. Don't fight it, embrace it. And both communities can 'cross-pollinate' and learn from one another ;)))

Edit: and I don't think a settings (can even be a hidden one, only for expert users) to disable the audio behavior can't be that hard to implement?

[hyttmi]

Thanks for the addon @OPHoperHPO !

[nikogusm]

hi all, the @OPHoperHPO fix is not working for me. I am running HA on a raspberry os in a docker container

this is a lot frustrating because I have another service on raspberry that is running for audio and the hassio_audio always takes over everything :(

[Lipown]

@nikogusm same here :/

[mightymergz]

After learning way more than I wanted to about PulseAudio I found a simple fix to this issue.

In /etc/pulse/client.conf put default-server = unix:/usr/share/hassio/audio/external/pulse.sock

The Home Assistant Supervisor starts the pulseaudio server inside the docker container. (This is a very aggressive pulseaudio instance as it always takes over the sound and doesn't let them go. The supervisor is also watching closely to make sure its pulseaudio is always running so it is very difficult to kill.)

The docker container exposes the pulseaudio unix socket from inside the container at /data/external/pulse.sock mounted to /usr/share/hassio/audio/external/pulse.sock. Outside of the container the pulseaudio system does not know where to find the socket provided for by the hassio pulseaudio. I think it was intended to still work automatically, maybe it does on debian, but not on raspbian, at least not mine. (see https://github.com/home-assistant/plugin-audio)

[simonemarin]

None of the proposed solutions worked for me unfortunately. RPI4 Raspbian and HA in Docker.

[simonemarin]

After learning way more than I wanted to about PulseAudio I found a simple fix to this issue.

In /etc/pulse/client.conf put default-server = unix:/usr/share/hassio/audio/external/pulse.sock

The Home Assistant Supervisor starts the pulseaudio server inside the docker container. (This is a very aggressive pulseaudio instance as it always takes over the sound and doesn't let them go. The supervisor is also watching closely to make sure its pulseaudio is always running so it is very difficult to kill.)

The docker container exposes the pulseaudio unix socket from inside the container at /data/external/pulse.sock mounted to /usr/share/hassio/audio/external/pulse.sock. Outside of the container the pulseaudio system does not know where to find the socket provided for by the hassio pulseaudio. I think it was intended to still work automatically, maybe it does on debian, but not on raspbian, at least not mine. (see https://github.com/home-assistant/plugin-audio)

In my installation the volume is mounted in another location /home/pi/Docker/Hassio/audio | /data so I changed the settings in client.conf accordingly but the issue is still there.

[fleXible]

I needed a different pulseaudio config, because it messes with my non-audio bluetooth devices. After lots of trial and error I settled for this solution injecting a shell-script into the hassio-audio s6 startup:

#!/bin/sh

# disable bluetooth module
sed -i -E 's|(load.+bluetooth-discover)|#\1|' /usr/share/tempio/system.pa

# enable suspend-on-idle
grep -q -F "module-suspend-on-idle" /usr/share/tempio/system.pa || \
  echo "load-module module-suspend-on-idle" >> /usr/share/tempio/system.pa

Save this shellscript under /usr/share/hassio/share/s6-scripts/01_fix_pulseaudio.sh and mount it into /etc/cont-init.d/ in your hassio-audio container. It's easily done with Portainer.

The script changes the template, used by hassio_audio to create /etc/pulse/system.pa. The filename makes sure to execute before that.

[shanness]

@fleXible thanks for that info. Could you explain what you mean by "easily done with portainer"? I googled it and installed it (via docker) and had a poke around, could see the hassio-audio container and after some painful banging around, tried adding a volume to the container, but it didn't stay there. There is probs a simple docker command to run to add it instead of using portainer I assume?

I managed to do what you suggested on this file, then ran docker restart hassio_audio then systemctl restart --user pulseaudio.service

Get the directory via

root@home:~# docker inspect hassio_audio  | grep merg
                "MergedDir": "/var/lib/docker/overlay2/c977b68a81b3c0f63753573898be51af10633a8263eb065538529416b049a0ef/merged",

vi /var/lib/docker/overlay2/c977b68a81b3c0f63753573898be51af10633a8263eb065538529416b049a0ef/merged/usr/share/tempio/system.pa

Seems to be working so far (although I still have the audio fix hack plugin installed, so hard to be sure).

[shanness]

Damn... Hasn't fixed it. My audio was broken again until I went in and restarted the the hassio_audio_fix again..

So sick of this annoying problem. Does anyone know how to at least force it to use my HDMI sink so it won't interfere with my sound system and headset?

[shanness]

Figured out how to do it at runtime at least. docker exec -it hassio_audio pactl list short sinks # List the sinks docker exec -it hassio_audio pactl set-default-sink alsa_output.pci-0000_07_00.1.hdmi-stereo-extra2 # Set it to one I don't use

[simonemarin]

This is what I get :

pi@RPI4:~ $ docker exec -it hassio_audio pactl list short sinks 0 auto_null module-null-sink.c s16le 2ch 44100Hz SUSPENDED

pi@RPI4:~ $ pactl list short sinks 0 auto_null module-null-sink.c s16le 2ch 44100Hz SUSPENDED

[fleXible]

Unfortunately I had to find out, it has to be done at runtime, because on restart, all containers are recreated from scratch :/

[shanness]

I think I've got a fix finally for this nasty problem that keeps breaking my mic and sound outputs on the host system (nasty problem when mic can't be accessed during meetings or gaming, and have people yelling "Hello" at me as I scramble to fix it). Was almost at the point I was going to give up and delete HA..

Basically instead of setting the default to hdmi (which turns off regularly), I now load module-null-sink and set the default sink/source in hassio-audio to the null sink/source, as well as unloading module-switch-on-connect and module-switch-on-port-available

And I've integrated it into this great system service wrapper that monitors the hassio-audio docker container and re-runs it on every restart. Pretty simple instructions on how to set it up including a systemd service file.

Seems to be working perfectly, and should be immune from breaking from changes to the hassio containers. It's keeping HA to stay away from all actual audio devices. I've put in a pull request to the forked repo, so perhaps use that instead of mine once/if merged.

https://github.com/shanness/HomeAssistant-PulseAudio-Disable

Feedback welcome, hope this solves it for others. It might be worth unloading the suspend module before loading it like the addon does (I assume to make it suspend them all immediately). I'll keep an eye on my logging to see if it's needed, and post here if I update the script.

[alanmilinovic]

I think I've got a fix finally for this nasty problem that keeps breaking my mic and sound outputs on the host system (nasty problem when mic can't be accessed during meetings or gaming, and have people yelling "Hello" at me as I scramble to fix it). Was almost at the point I was going to give up and delete HA..

Basically instead of setting the default to hdmi (which turns off regularly), I now load module-null-sink and set the default sink/source in hassio-audio to the null sink/source, as well as unloading module-switch-on-connect and module-switch-on-port-available

And I've integrated it into this great system service wrapper that monitors the hassio-audio docker container and re-runs it on every restart. Pretty simple instructions on how to set it up including a systemd service file.

Seems to be working perfectly, and should be immune from breaking from changes to the hassio containers. It's keeping HA to stay away from all actual audio devices. I've put in a pull request to the forked repo, so perhaps use that instead of mine once/if merged.

https://github.com/shanness/HomeAssistant-PulseAudio-Disable

Feedback welcome, hope this solves it for others. It might be worth unloading the suspend module before loading it like the addon does (I assume to make it suspend them all immediately). I'll keep an eye on my logging to see if it's needed, and post here if I update the script.

I tried setting things up with systemd but it is not working automatically, once the system boots up. I am getting "Connection refused" failure, but restarting the service manually works. I think this loop function is not looping or get stuck in the early stage after reboot. I have NUC and MX Linux.

[alanmilinovic]

Now it looks like it is not working at all. Running manually "module-suspend-on-idle" command is returning number 16 but still no sound at all. Any help?

[alanmilinovic]

Ok, I am moving forward.

As I have bluetooth device connected to my host, I had to disable bluetooth in hassio_audio container by adding following line to Shanness script. docker exec -i hassio_audio pactl unload-module module-bluetooth-discover

I also autostart Kodi on my system and had to start service once Kodi is up and running. sudo systemctl start pa-suspend

Not sure why script doesn't work if executed before Kodi starts.

[bogdanni]

I measured a power saving of 1W+ on my basement mini computer which runs a minimal Linux installation dedicated to HA. Using powertop I noticed hundreds of events/s from pulseaudio, which is not even installed on the host.

This did it for me: docker exec -it hassio_audio pactl load-module module-suspend-on-idle

I believe that the audio device (this Audio codec hwC0D0: Realtek) was kept kept active 100% by pulseaudio. Many kWh must be wasted around the world by this feature of HA.

[shanness]

I tried setting things up with systemd but it is not working automatically, once the system boots up. I am getting "Connection refused" failure, but restarting the service manually works. I think this loop function is not looping or get stuck in the early stage after reboot. I have NUC and MX Linux.

Ahh, thanks for pointing that out. I hadn't rebooted when I tried it. I've fixed it now I think. Put a sleep in after killing pulse in the docker container. The problem was pulse hadn't restarted when my additions were run.

I was having the same problem too, but hadn't got around to debugging it. Seems fixed now for me @alanmilinovic

[alanmilinovic]

I tried setting things up with systemd but it is not working automatically, once the system boots up. I am getting "Connection refused" failure, but restarting the service manually works. I think this loop function is not looping or get stuck in the early stage after reboot. I have NUC and MX Linux.

Ahh, thanks for pointing that out. I hadn't rebooted when I tried it. I've fixed it now I think. Put a sleep in after killing pulse in the docker container. The problem was pulse hadn't restarted when my additions were run.

I was having the same problem too, but hadn't got around to debugging it. Seems fixed now for me @alanmilinovic

Just tested and it is working now great, thank you. What I would also add to your code is disabling bluetooth module in container, others had also issue with bluetooth. If you agree I can create a pull request?

[fleXible]

@alanmilinovic Thanks to e-mail notification, I came back here just in time to take the bluetooth commands. Thx a lot guys. Though it's amazing what an endless timesink this has been but the HA teams is still not willing to put in a switch for everyone interested...

[shanness]

Just tested and it is working now great, thank you.

Great! good to hear. It's been a nightmare for me until I figured out the null sink/source could be used! I'm actually moving to putting hassio on a VM (found a HP Proliant ML350 G6 in my apartments recycling :).

What I would also add to your code is disabling bluetooth module in container, others had also issue with bluetooth. If you agree I can create a pull request?

Sure mate, go ahead. I'd suggest putting a config option for it at the top to control if it gets used like I did. Then I'll merge it and it will become part of my pull request.

[chatziko]

Here's a nice workaround for anyone who's interested. If in the host system you are using only alsa, you can instruct HA's pulse to ignore a certain card via udev. Just create a file /etc/udev/rules.d/89-pulseaudio.rules with the following content:

DRIVERS=="bcm2835_audio", ENV{PULSE_IGNORE}="1"

If needed, replace "bcm2835_audio" with the driver of your card, you can find it with

udevadm info -a -p `udevadm info -q path -n /dev/snd/controlC0`

(or Control1, etc).

This workaround doesn't involver any changes in HA, so it should persist updates. HA's pulse will run happily with any remaining cards in the system (or no card at all), and you can still use alsa in the host.

[piotrret]

This is probably the only good solution. On my laptop it works fine with the integrated intel card. I've been looking for this for hours and finally found it. Thanks a lot

[nehasjains]

I installed Homeassistant supervised on raspberrypi 4 running on debain 11

Please guide how to solve the following issues:-

How do I autostart pulseaudio and connect to bluetooth? I have already installed pulseaudio and I am able to connect to bluetooth speaker manually via the terminal. It is possible to autostart pulseaudio and connect to bluetooth speaker automatically once the homeassistant is started?

How can I change the default media path? Kindly guide

[DivanX10]

After learning way more than I wanted to about PulseAudio I found a simple fix to this issue. In /etc/pulse/client.conf put default-server = unix:/usr/share/hassio/audio/external/pulse.sock

In this case, the microphone in the bluetooth headset does not work. In fact, to output audio to a bluetooth headset, it doesn't matter whether we use default-server = unix:/usr/share/hassio/audio/external/pulse.sock or default-server = . The sound goes to the bluetooth headset anyway, but the microphone on debian 11 works if instead default-server = unix:/usr/share/hassio/audio/external/pulse.sock, we indicate how it was by default there is default-server = I can't throw the bluetooth microphone in the Home Assistant. I have described in detail here about my problem and what I did. I do not know how to overcome this problem.