Closed frkos closed 4 years ago
Ohh.... it's upgraded back to 9 automatically =(
DEL
NVM, load the module for IDLE manual with pactl
is there a quck way to disable this? How to downgrade to an usable version?
where to find the ha binary? It's not present in any of the containers...
a temporary fix:
service hassio-supervisor stop docker stop hassio_audio
Afte this, homeassistant stops working for about 3 minutes then it comes back and is usable.
Well, you can just load manually the IDLE module for PulseAudio... just use google for the commands on PulseAudio. As the docu said, you have the full control of Pulse
@pvizeli I'm running into this issue on Ubuntu 18.04. I looked into loading module-suspend-on-idle
for pulseaudio, but my /etc/pulse/default.pa
file already has it loaded. Is there somewhere else I should be looking?
@pvizeli What was the reasoning for https://github.com/home-assistant/audio/pull/11? This has hosed two machines I'm running both home-assistant and mythtv on since the audio no longer works in mythtv.
@pvizeli
I also don't understand what you mean by this. I think you mean I should configure pulse audio in the hassio_audio container, but if I do so using docker run
changes will not be persistent.
Is there anything I can change in /usr/share/hassio/audio
to make hassio_audio not steal my host pc audio, as I currently don't want to have hassio_audio
. This might change in the future, but as of right now, this is not sufficient for my use case. The only way that quickly worked is what @dimovnike mentioned. But turning off hassio_supervisor and hassio_audio is probably a bit much.
How do I permanently disable hassio_audio from running? It breaks pulse audio on the host system.
journalctl --since "1 day ago" | grep pulseaudio
shows messages like these:
Mar 11 22:58:43 hades pulseaudio[1840]: [alsa-sink-ALC700 Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Mar 11 22:58:43 hades pulseaudio[1840]: [alsa-sink-ALC700 Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Mar 11 22:59:20 hades pulseaudio[1840]: [alsa-sink-ALC700 Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Mar 11 22:59:27 hades pulseaudio[1840]: [alsa-sink-ALC700 Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Mar 11 22:59:27 hades pulseaudio[1840]: [pulseaudio] sink-input.c: Failed to create sink input: sink is suspended.
Rebooting the host I can get audio back for a few minutes before these messages begin appearing again.
Edit: Trying to play YouTube on Chromium on the host system; the video gets stuck loading with a message: "If playback doesn't being shortly, try restarting your device."
If I kill hassio_audio container, the video begins to play immediately.... Once video playback on the host stops and hassio_audio has booted up again, it's back to "If playback doesn't being shortly, try restarting your device." on the next video.
You need to use the pactl
tool over the Terminal add-on to load the IDLE module if you need this.
The Supervisor is designed to get full control over your to host and everything is running as an add-on. If you use it differently, it ends up with such issues and they can get more in the future. You should maybe look into the OVA (OpenVirtualAppliance) or just use the Core installation.
I'm running HA on a x86 pc, that I also use as desktop and for various other things. I know that hassio is primarily run on raspberrys. Given that more of this will happen in the future, it might be a good time to switch to a virtual machine to host the hassio instance. I'm a bit worried about mapping all the USB devices, as I have about 20 of them or so, but it might eventually work.
That is the out of the box handling with supervisor: host -> supervisor -> add-ons. However, you can manage the PulseAudio instance by your self and tweak what do you want.
The Project have just 1 developer and that is me. If someone will jump into and maintain the generic installer with all issues and use case to make sure it work like you need, welcome to the team. But the size of the project and that is all maintain by just 1 person make that we need focus me to to the roots. Home Assistant is a full manage system with allow to run the Supervisor on Debian/Ubuntu. However, the nature of the Supervisor is the same. If you want manage all by your self, you can just install the Core.
The Project have just 1 developer and that is me
You don't need to justify anything to me. I'm very happy for your work. :)
Putting hassio in a dedicated VM should be fine as well or am I wrong? This would also be future proof, as hassio can do in the VM what ever it likes. Plz correct me if I'm wrong as I would like to give that a try soon.
Per @pvizeli's clue, I believe these are the steps to get hassio audio to release audio back to the host:
Terminal & SSH
add-on from the supervisor, start it, add it to the sidebarTerminal
tab from the sidebar pactl load-module module-suspend-on-idle
This should release the ALSA sink back to pulse audio on the host until the next _hassioaddon container restart.
@pvizeli I would still like to know the reasoning for #11 as it seems to be causing more issues than it's solving.
why is not module-suspend-on-idle loaded on default? Is there a reason for it? Or there are other addons that actually use pulse audio?
However, you can manage the PulseAudio instance by your self and tweak what do you want.
This is only somewhat true, since a reboot of the host will reset things to default. Is there a way to persist my changes? I would prefer to stick with using the supervisor since there seems to be very little documentation for just installing and using Core in my brief searching.
I have the same problem, on my PC host system (Ubuntu 18.04.4, Kernel 5.3.0-40) there is no sound and microphone on host system. I have homeassistant 0.106.6, supervisor 209. I'm not using any of audio steam/pass options in homeassistant, so I can live without it.
It's not working in my case:
pactl load-module module-suspend-on-idle
For my the best solution would be to turn off hassio_audio
container from run by supervisor. Is there any option to do that?
I’m in the same situation as the others - I run home-assistant through hass.io on a multipurpose x86 computer and suddenly lost sound on the host - it took a while to diagnose if I’m honest. I understand the intention of this container/project and will probably just build out a docker compose of all the things the hass.io install does (e.g. all the add-ons I use) currently but that’s a bigger project...
What worked for me (at least so far) was to stop and remove the audio container, as it looks like the supervisor gets a bit confused when it expects an image to be available locally and it isn’t.
# as root or prefixed with sudo:
docker stop hassio_audio
docker image rm -f homeassistant/amd64-hassio-audio:9
Super hacky but I couldn’t work out a way to tell the supervisor not to start the audio container, or a way to persist which pulse/alsa modules are loaded.
@fourseven
Thank you, I removed hassio_audio image.
Before
~ $ sudo fuser -fv /dev/snd/* USER PID ACCESS COMMAND /dev/snd/controlC0: root 373 f.... alsactl systemd-timesync 4229 F.... pulseaudio /dev/snd/pcmC0D1p: systemd-timesync 4229 F...m pulseaudio /dev/snd/pcmC1D0c: systemd-timesync 4229 F...m pulseaudio
Now
~ $ sudo fuser -fv /dev/snd/* USER PID ACCESS COMMAND /dev/snd/controlC0: root 365 f.... alsactl
@fourseven I thinking restarting hassio_supervisor will just cause hassio_audio to be reinstalled again...
Maybe if we can tag a dummy container as "homeassistant/amd64-hassio-audio:9" we can get around it that way.
@deftdawg Yes, after second reboot hassio_audio came back. Maybe with a script or service on boot, something like: sleep ... hassio_audio = sudo docker ps | grep hassio_audio if hassio_audio docker stop hassio_audio docker image rm -f homeassistant/amd64-hassio-audio:9 sudo reboot
@deftdawg so:
docker pull homeassistant/amd64-hassio-audio:8
docker image tag homeassistant/amd64-hassio-audio:8 homeassistant/amd64-hassio-audio:9
😂
Can we get a setting added so the host retains control over the audio?
I would prefer to keep using the supervisor as using the addon store is WAY more convenient than spinning up the docker containers yourself.
If there is a way to play audio files and do TTS directly from Home Assistant without needing access to the host system or Chromecast/Alexa I'm all ears.
@deftdawg so:
docker pull homeassistant/amd64-hassio-audio:8 docker image tag homeassistant/amd64-hassio-audio:8 homeassistant/amd64-hassio-audio:9
😂
I tried that and it worked fine through a few test restarts but this morning at 8AM it pulled the new version again...
Can we get a setting added so the host retains control over the audio?
I would prefer to keep using the supervisor as using the addon store is WAY more convenient than spinning up the docker containers yourself.
If there is a way to play audio files and do TTS directly from Home Assistant without needing access to the host system or Chromecast/Alexa I'm all ears.
That would be perfect. Maybe expose the pulse server back to host?
I developed a small add-on for hass.io that automatically fixes this problem (it executes the pactl load-module module-suspend-on-idle
command) every time the container with the home assistant is restarted.
Warning!
This is a very dirty temporary hack
, but it works.
Thanks @OPHoperHPO!! I still want to know why the module can't be loaded by default...
I developed a small add-on for hass.io that automatically fixes this problem (it executes the
pactl load-module module-suspend-on-idle
command) every time the container with the home assistant is restarted.
Can you explain to me how to do the installation? I tried it through Hacs, but when I try to add as a custom repository an error appears. Thanks.
@rubenslook Use https://github.com/OPHoperHPO/hassio-addons as your custom repository.
@rubenslook Use https://github.com/OPHoperHPO/hassio-addons as your custom repository.
I don't recognize that screen at all. What version of HA/supervisor are you running?
I'm sorry, I found it.
I developed a small add-on for hass.io that automatically fixes this problem (it executes the
pactl load-module module-suspend-on-idle
command) every time the container with the home assistant is restarted.
Thanks for this!!
Struggling with this issue as well..
I don't recognize that screen at all. It was HACS screen, everyone knows this )
Thank you so much, I’ve been looking for a solution to this problem for a long time.
What I did:
Edit /etc/pulse/default.pa sudo nano /etc/pulse/default.pa Comment line where module-suspend-on-idle is loaded:
Force load at boot of HDMI sink (is what I need) load-module module-alsa-sink device=hw:0,3
After rebooting HDMI can be selected in Settings-Sound so I have to change Dummy Sound and select HDMI. Also I have to select HDMI Configuration for Output 5.1 for make it work,
Even if hassio_audio is running Audio is connected to HDMI. If you experience problems in startup I think stopping hassio_audio just once make HDMI work until next reboot at least.
Regards.
I developed a small add-on for hass.io that automatically fixes this problem (it executes the
pactl load-module module-suspend-on-idle
command) every time the container with the home assistant is restarted.
Thanks so much for this @OPHoperHPO ! I had been troubleshooting for hours before i figured out that it was caused by the audio container - your add on fixed the problem and saved me a huge headache
Please make the hassio_audio service optional and [OFF] by default, as it causes unexpected changes to the host system (unexplained loss of audio playback).
Please add warning about potentially losing audio from the system if this service is enabled.
Please change docker restart policy for this container form 'always' to 'unless stopped'
This is very annoying and wasted a lot of time when people have to troubleshoot sudden problem with no audio in their system.
Is the use case for host audio via hassio_audio more of an edge case than running hassio in a non-dedicated Docker host?
I'm not arguing that most users probably deploy to a dedicated host like an RPi, but rather what proportion of users actually plug a speaker into the audio jack (or make use of sound over HDMI without running a desktop) and make use of it?
Is there an integration or scenario where it's commonly used? I'm genuinely curious.
I think it's used for voice commands ("Hassio, set my se* dungeon lights to blood red!"). But If I have audio output from RPI, I'd use it for movies/youtube/spotify rather than voice commands. But I suppose it's the opposite for other people.
i've been without audio for 3 months because i couldn't debug the problem and i didn't know it was the fault of this shitty container!!!!!! why take system audio???? docker is supposed to exist to separate things from system not to break the system. holy F!!!
@felixsanz Home Assistant is not just a Docker container. If you would like the more isolated approach on a pure containerized system, please use Home Assistant Core, which is available as just a Docker image.
Furthermore, please note, we have a Code of Conduct. There is no need to use those last words in your comments. Thanks 👍
@frenck There's a lot of frustration in this thread because no one has answered the question of why the audio container takes over the host audio. It's been asked multiple times, and the pull request which made the change doesn't say why it was needed either. Can someone answer this?
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.
@frenck I understand that, but what was broken before that caused the need to remove the suspend-on-idle module in #11?
Popping sound when the audio channel was used on some single-board systems.
Popping on the input side messing up captures? Or popping on output during playback? Any board makes/models specifically? Raspberry Pis?
Playback for sure, haven't tested the input myself.
However, it is not relevant, as this has been solved.
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