There is a whole discussion in Github going about disabling audio in HA, but the developers won’t bite.
I suspect there is a fair amount of HA users who don’t care about the audio, and it just consumes resources and wears out your SD/SSD by writing trace data to the log.
There seems to be a HA addon that will stop PulseAudio, albeit for a different reason. But you may want to try this as a (temporary?) workaround until the root cause is fixed.
The add-on doesn’t work here
Yep, running HA on a RPi 4.
Is this logged somewhere as a showstopper error?
@corgan apparently experiences the problem for “some days” already, and it is not fixed yet.
What do we have that is different? If all HA users experience this problem there would have been a major outcry. Or… they don’t know they have it?
Perhaps they didn’t restart their host, yet.
It’s also interesting if this happens on armhf / armv7 only.
I have RP3 (Rasbian OS and trying to use HA Supervisor) and same problem. Im trying to restore my snapshot but this error seems to be causing problems, if i paused HA audio it started to move something.
What I have seen, this problem only appears on unsupported installations, like mine (Raspbian 10 Buster) and if you reboot your system after an apt-update.
The HA-Audio Add-on caused the problem, but the developer are really like these old school linux gurus in the forums in the old days. It’s not official supported, so we don’t care. Re-install and let take HA in control the system. That everything runs totally fine (except ha-audio), doesn’t matter.
That basically what they told the several other users.
OK, you can act like this, but that’s for me the first time i that i must read something like that in this community.
For me, the biggest question is, why the developer don’t give us the choice to deactivate this crap ha-audio add-on. I don’t need anything from it. There are so many people here in the Forum and on GitHub begging for it, but we don’t even get an answer, why we can’t deactivate it. And this arrogant behavior really shocked me.
I have a huge setup with hundreds of sensors from outside ha. Reinstallation is no option, because i don’t have the time that this would take. Everything would be fine, if we only could deactivate a (for me) useless add-on.
If you have time, here are some best-of ha-audio problems.
Forget to mention, I still don’t have a solution. The OPHoperHPO/hassio-addons only works on the last version and is not updated to work on the new ha.audio.
I searched hours for a “not that hacky” docker rm ha-audio container solution, but there is nothing i can do atm, as to look at my logfiles size going crazy…
Today:
oh and I forgot to mention, that the system load increased by 50% and the cpu temp by around 10°C… Since i did the last update…
I think this error is keeping my sensor graphs flat lined too. Correct data is shown with number but graph stays still.
@ToreTigu I had this when my previous SSD failed. HA was still running, buttons and automations still functioned as if nothing was wrong. But when I rebooted the RPi at some point it just hanged and nothing happened. Turned out the SSD was in read-only mode as a way to prevent data loss, but I could not write to the disk anymore. This allowed me to make images of the boot and root partitions and restore that later to my new disk.
If you did not reboot/restart yet since you saw this, make sure you have a backup that you can restore later. If you can still create a HA snapshot, then you’re good and a disk failure seems not the cause. If you can’t, and you don’t have a recent snapshot, then at the very least you can edit your files and copy/paste the contents to files in Windows or wherever. Depending on what you’ve done with HA, I would consider e.g. configuration.yaml, secrets, scripts, automations, … , and go into Lovelace raw edit and copy the full definitions of your pages.
@JoFie I have a snapshot, i just restored from it. HA runs on RP3 SD card, somewhat new card. Before restoring it worked fine on same SD but as HA OS, now it’s Rasbian OS and HA Supervised in Docker.
Did someone of you tried to
pause supervisor
remove hassio_audio:2021.2.1
pull hassio_audi:17
tag hassio_audio:17 with hassio_audio:2021.2.1
start supervisor
??
I restored my installation and I don‘t want to restart it, so I can’t try myself.
I confirm the same problem. Raspberry Pi 3B, Home-Assistant Supervised in Docker on Raspbian (HA 2021.1.5, Superviser 2021.02.11). And yes, it all started after updating and rebooting. The log for 12 hours already takes 195 MB.
And, like many others, I don’t use audio at all
I can try. But please describe in more detail what commands I should enter, I’m not very good at Linux and Docker yet
Do you have Portainer installed?
Yes, but haven’t updated it for a long time. Currently installed version 1.23.2
Try to pause the supervisor and delete hassio_audio.
Have a look if it stays away or if the supervisor reloads it.
OK, I’ll try in an hour.
Maybe disabling audio in /boot/config.txt will solve the problem? For example, as described here https://radio-docs.netlify.app/docs-audio
I tried your recommendation to load an earlier version of hassio_audio, and it works!
As expected, it takes a little bit before the (new) hassio_audio container is started, but now HA fully works, including the “Supervisor” screen.
Below are the commands I executed, if others want to try.
docker pause hassio_supervisor
docker stop hassio_audio
docker container rm hassio_audio:2021.2.1
docker rmi <image ID>
docker pull homeassistant/armv7-hassio-audio:17
docker tag homeassistant/armv7-hassio-audio:17 homeassistant/armv7-hassio-audio:2021.2.1
docker unpause hassio_supervisor
You can get the image ID using: docker images
Interestingly after the tag change I now have two images, the downloaded version “:17” and also a new image with tag “2021.02.1”.
The danger here is that when the HA folks release a new hassio_audio version in which this problem is not fixed, the Supervisor will download it automatically in the background and the SD-killing problem will be back.
That was too quick… 
The hassio_audio container stopped after a while, and I see the following errors once a minute in the Supervisor logs:
21-02-21 16:20:58 INFO (MainThread) [supervisor.plugins.audio] Starting Audio plugin
21-02-21 16:20:58 INFO (SyncWorker_3) [supervisor.docker.interface] Cleaning hassio_audio application
21-02-21 16:21:00 INFO (SyncWorker_3) [supervisor.docker.audio] Starting Audio homeassistant/armv7-hassio-audio with version 17 - 172.30.32.4
21-02-21 16:22:00 WARNING (MainThread) [supervisor.misc.tasks] Watchdog found a problem with PulseAudio plugin!
21-02-21 16:22:00 INFO (MainThread) [supervisor.plugins.audio] Starting Audio plugin
21-02-21 16:22:00 INFO (SyncWorker_3) [supervisor.docker.interface] Cleaning hassio_audio application
21-02-21 16:22:01 INFO (SyncWorker_3) [supervisor.docker.audio] Starting Audio homeassistant/armv7-hassio-audio with version 17 - 172.30.32.4
It knows it is version 17.
Last error in the Audio logs:
[cont-init.d] executing container initialization scripts...
[cont-init.d] alsa-mixer.sh: executing...
[17:25:06] INFO: Adjust ALSA mixer settings for /dev/snd/controlC0
[17:25:07] INFO: Adjust ALSA mixer settings for /dev/snd/controlC1
[cont-init.d] alsa-mixer.sh: exited 0.
[cont-init.d] pulse-config.sh: executing...
[cont-init.d] pulse-config.sh: exited 0.
[cont-init.d] setup-filesystem.sh: executing...
mount: permission denied (are you root?)
[cont-init.d] setup-filesystem.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.