Open Rastafabisch opened 6 months ago
I fixed it, even though I do not like the fix…
What makes it work is passing through said /etc/asound.conf
file as a volume in the docker-compose.yaml
file.
This means however, that the container does not respect the hosts set audio device (if overwritten using alsamixer, etc.). I would prefer that the audio outputs wherever I tell the host to route it to. This however appears to be a docker issue, rather than a shairport-sync one.
Nonetheless, if anyone has any suggestions as to how achieve my desired behaviour I'd be glad to hear about it.
That said I think it might be good idea to incorporate my findings into the official yaml file.
#volumes:
# - /etc/asound.conf:/etc/asound.conf # Respect the hosts configured default audio device
Hello Community, hello @mikebrady!
First off: Thank you for the great work being done!
Now to my issue: I got a somewhat rare problem. I think. After experimenting with my SBC (Rock 5B) for the past month I finally settled for a kernel (6.1.43-rockchip).
Sometime early on I already had
shairport-sync
running perfectly fine with the stockshairport-sync docker-compose.yaml
. However now I do not get any AirPlayed audio anymore. Searching for a solution I realised that with my current kernel defaults to HDMI-audio. I fixed this with an/etc/asound.conf
file configuring the headphone jack as the default output device. This apparently works fine as I can just play something on the (headless) host usingaplay ./test.wav
.However I still do not get any output via AirPlay. I already checked the docker containers
shairport-sync.conf
, but it looks good to me, not specifying anything, and thus defaulting toalsa
, and whatever the host does (at least this is how I think it works).Now I hit a dead end as to what else to try. Any help is appreciated.
Best Rastafabisch
EDIT: I also tried restarting the SBC and the docker container - no dice.