mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1478] librespot crashes if alsa device is temporary not available #664
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#664
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ers4691 on GitHub (Mar 22, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1478
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.
librespotwith an alsa device, currently not availableLog
https://pastebin.com/xemUBTUq
Host (what you are running
librespoton):Additional context
@kingosticks commented on GitHub (Mar 22, 2025):
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.
@photovoltex commented on GitHub (Mar 22, 2025):
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.@ers4691 commented on GitHub (Mar 22, 2025):
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....
@kingosticks commented on GitHub (Mar 23, 2025):
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.