Hassio-audio / pulse audio not finding raspberry pi devices - how to configure

Hi all, relative newbie here. tl;dr - I need some pointers on how to understand what pulseaudio is doing within hassio-audio as it isn’t finding RPi devices, but I can see the alsa devices from within the hassio-audio container.

Let me start with my overall setup: I have HA running on a Raspberry PI 4, using Hassio (so I can get community add-ons). There’s a front end that is running on a small touch screen, using a chromium browser in kiosk mode.

What I’m trying to do: get a chime sound to play to the headphone jack of the RPi. My understanding is that either (a) I can try to get this to play through browser_mod, or (b) set up something that passes through hassio-audio. In essence, since HA is running inside docker there needs to be communication back to the RPi devices.

Where I’ve been:

  • Originally I used browser_mod to register the chromium browser, and had it working for a bit. This seems to have stopped working after a reboot; I spent some time reconnecting the browser and making sure the no-gesture-required policy was set, long story short I feel like this is just too brittle, so I’m looking for an alternative.
  • I played around with a number of the alternatives that I found in the forums, etc: setting up VLC, local VLC, and one other option that I’m forgetting. None of them could see anything but a “default” device.
  • I am able to play the audio file from outside any containers using aplay (alsa). The RPi has three devices: two HDMI device and the headphone jack - it’s the latter that I want to use.
  • I jumped into the hassio-audio docker and found something interesting: when I look at pactl the sinks listed, it only finds a dummy sink:
Sink #0
	State: IDLE
	Name: auto_null
	Description: Dummy Output
	Driver: module-null-sink.c
	Sample Specification: s16le 2ch 44100Hz
	Channel Map: front-left,front-right
	Owner Module: 14
	Mute: no
	Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
	        balance 0.00
	Base Volume: 65536 / 100% / 0.00 dB
	Monitor Source: auto_null.monitor
	Latency: 1727653 usec, configured 2000000 usec
	Flags: DECIBEL_VOLUME LATENCY SET_FORMATS 
	Properties:
		device.description = "Dummy Output"
		device.class = "abstract"
		device.icon_name = "audio-card"
	Formats:
		pcm

But when I run aplay -L from within the container I can see the RPi devices:

hassio-audio:/# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
sysdefault
    Default Audio Device
pulse
    PulseAudio Sound Server
default
    Default ALSA Output (currently PulseAudio Sound Server)
sysdefault:CARD=vc4hdmi0
    vc4-hdmi-0, MAI PCM i2s-hifi-0
    Default Audio Device
hdmi:CARD=vc4hdmi0,DEV=0
    vc4-hdmi-0, MAI PCM i2s-hifi-0
    HDMI Audio Output
sysdefault:CARD=vc4hdmi1
    vc4-hdmi-1, MAI PCM i2s-hifi-0
    Default Audio Device
hdmi:CARD=vc4hdmi1,DEV=0
    vc4-hdmi-1, MAI PCM i2s-hifi-0
    HDMI Audio Output
sysdefault:CARD=Headphones
    bcm2835 Headphones, bcm2835 Headphones
    Default Audio Device

Indeed, I can play the wave file from inside the container:

aplay --device=sysdefault:CARD=Headphones /media/chime.wav

but this just returns silence for the duration of the file (i.e. not the right device):

paplay /media/chime.wav 

So, all this said, it looks to me like the auto-discovery isn’t working within the container. (I also am not quite sure why pulse audio isn’t running as a daemon, which prohibits use of pactl.)

Any idea on how to work with pulse audio within hassio-audio to find the devices within the container?

You could use the squeezelite addon GitHub - pssc/ha-addon-squeezelite: Squeezelite Player Addon for Home Assistant, for use with a Logitech Media Server and the slimproto integration. SlimProto (Squeezebox players) - Home Assistant

1 Like

That looks interesting. General idea is to run something like piCorePlayer a squeezelite client on the RPi side and then talk to it via Squeezelite/Slimproto? (pCP looks to be a general “take over the OS” installation.)

I didn’t suggest picoreplayer. I am suggesting running squeezelite.

@nickrout Thanks. I had written one response asking a question but I realize that I need to do some more research.

My impression is that I shouldn’t need to run the squeezelite player add-on if I run squeezelite natively on the RPi side, with SlimProto providing the bridge between hassio and the RPi, right?

You can’t run picoreplayer and HAOS on the same pi.

I’m not and wasn’t intending to - my question was about squeezelite. Sorry - my (deleted) long-winded answer had explained that. But after poking at it I did find the workaround I was looking for. Will document next

1 Like

OK, based on the idea that @nickrout provided, I used the following workaround; documenting for others.

Within hassio:

  • Install SlimProto
  • no need for the squeezelite player

On the RPi side (outside docker):

  • Install: sudo apt install squeezelite
  • Run: squeezelite -n RPi_audio -f /dev/null -o hw:CARD=Headphones,DEV=0

Within HA:

  • Go to Settings > Devices & Services > Slim Proto Player, and then click on the device. It will originally be turned off (hence my confusion). Turn it on and you can play media through it.

BTW I found that when running squeezelite I got a number of errors at a regular interval, but it seems to work anyway. Hence the redirection to /dev/null to get rid of the errors but if folks have suggestions on what might cause those messages, glad to hear.

squeezelite -n RPi -o hw:CARD=Headphones,DEV=0
[14:01:20.495325] process:532 unhandled vers
[14:01:20.495556] process:532 unhandled grfb
[14:01:20.499568] process:532 unhandled grfe
[14:01:25.505410] process:532 unhandled grfe
[14:01:29.309742] process:532 unhandled vers
[14:01:29.310300] process:532 unhandled grfb
[14:01:29.319753] process:532 unhandled grfe
[14:01:34.326443] process:532 unhandled grfe
[14:01:35.030882] process:532 unhandled grfb
[14:01:35.044721] process:532 unhandled grfe
[14:01:38.258495] process:532 unhandled grfe
[14:01:39.330699] process:532 unhandled grfe
...

Those errors don’t occur if I run a LMS on my mac and connect to it, so it seems to be a SlimProto incompatibility.

Anyway, this doesn’t answer my original question directly (and I’ve found more intriguing error messages in the audio logs), but it does solve the original problem for me, so thanks to @nickrout for the pointer in the right direction.

Side notes on the above: on the RPi, if you try to set this up to launch on boot with the RPi/squeezelite using autodiscover to find the HA SlimProto, it takes too long to boot HA and squeezelite’s autodiscover seems to time out. I solved this by explicitly pointing squeezelite to the IP address of the HA docker container.

Also, the media server is started in the off state, so I ended up writing a rule that turned it on on HA boot, although I think I’ll need to check before sending it a sound anyway.