librespot-org
librespot crashes if alsa device is temporary not available
Description
Have a USB DAC as an alsa device, librespot crashes, if the USB DAC is switched of.
Version
librespot 0.6.0 383a6f6 (Built on 2025-03-02, Build ID: fJnuxGP3, Profile: release) librespot is running inside a container.
How to reproduce
Steps to reproduce the behavior in librespot e.g.
- Launch
librespotwith an alsa device, currently not available - See some error/problem
Log
https://pastebin.com/xemUBTUq
Host (what you are running librespot on):
- OS: Linux
- Platform: Docker giof71/librespot
Additional context
Do I understand correctly? You launch librespot and specify an audio device that doesn't currently exist (because you already switched it off)? What do you want librespot to do in this case? Exit more gracefully rather than crashing?? Or magically pick some other device to use, despite you explicitly specifying one? The latter makes no sense to me.
I think a graceful exit would be expected behavior, rather then a panic. It's technically not a bad behavior in itself, as we would stop the application anyways. But it's probably still considered a hard crash, especially when you build librespot optimized and remove the panic! handling.
Actually, I expect the same thing that mpd is doing in this case. Nothing at all when starting up, as nobody is accessing the ALSA device. I would only expect a ‘Device not found’ error when a client connects to librespot if the USB device is not switched on. If the device is switched on in the meantime, the music should of course be playing on it.
I think this is a completely normal use-case for USB DACs if you don't want to switch everything on all the time.
Since the whole thing runs in a Docker environment, I have exactly the desired behaviour. The container is permanently restarted until the USB ALSA device is switched on. However, I don't find this particularly elegant.
An alternative would probably be to connect a pulse-audio in between....
Ok, thanks for explaining. In the case of an internal soundcard it's reasonable to expect a fail-fast style behaviour but I think you can argue it either way. However, I see how the alternate behaviour is more flexible so seems a valid improvement for someone to take on.