[GH-ISSUE #1057] Error and termination when audio interface is removed or not available #497

New issue

Closed

opened 2026-02-27 19:30:59 +03:00 by kerem · 12 comments

kerem commented 2026-02-27 19:30:59 +03:00

Owner

Copy link

Originally created by @tweisberger on GitHub (Sep 5, 2022).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1057

Describe the bug
When the audio device is removed while Spotify connected to librespot endpoint or when connect while audio interface is not present, librespot terminates. librespot should handle this gracefully. This requires manual intervention.

This use case is using an external DAC connected to USB. When the DAC is set to another input away from USB, it removes the connection. Expected behavior would be to gracefully disconnect from Spotify. Or in the case where the audio device is not present, reject an incoming connection.

To reproduce
Steps to reproduce the behavior 1: _Audio interface is removed after connect: _

1. Set DAC to USB input (connection the device running librespot).
2. Launch librespot with
   sudo librespot --name Livingroom --bitrate 320 --format S16 --mixer softvol --initial-volume 70 --volume-ctrl log --volume-range 60 --autoplay --cache /var/local/www/spotify_cache --disable-audio-cache --backend alsa --device _audioout --onevent /var/local/www/commandw/spotevent.sh
3. Connect with Spotify on iOS (or macOS) client
4. Change input of DAC away from USB
5. See error

Behavior 2: Audio interface is not present when connecting :

1. Set DAC to input other then USB.
2. Launch librespot with
   sudo librespot --name Livingroom --bitrate 320 --format S16 --mixer softvol --initial-volume 70 --volume-ctrl log --volume-range 110 --autoplay --cache /var/local/www/spotify_cache --disable-audio-cache --backend alsa --device _audioout --onevent /var/local/www/commandw/spotevent.sh
3. Connect with Spotify on iOS (or macOS) client
4. See error

Log

Behavior 1 :
[2022-08-31T22:09:38Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'EIO: I/O error' [2022-08-31T22:09:38Z ERROR librespot_playback::player] Audio Sink Error On Write: <AlsaSink> ALSA function 'snd_pcm_recover' failed with error 'EIO: I/O error' pi@moode:~ $

Behavior 2:
[2022-08-31T22:07:05Z TRACE librespot_playback::player] == Starting sink == ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card [2022-08-31T22:07:05Z ERROR librespot_playback::player] Audio Sink Error Connection Refused: <AlsaSink> Device _audioout May be Invalid, Busy, or Already in Use, ALSA function 'snd_pcm_open' failed with error 'ENOENT: No such file or directory' pi@moode:~ $

Host

• Linux: 11.4 | 5.15.32-v8+ #1538 | aarch64 (64-bit)
• moOde audio player 8.1.2
• librespot 0.4.1 88e64bd (Built on 2022-07-07, Build ID: jEVg9nf8, Profile: release)
• Raspi: Pi-4B 1.5 2GB

Connecting Device

• SMSL DO100 USB DAC

Additional context
In the case of moOde, librespot terminates, and the device becomes unusable until the user connects to the web ui and manually restarts librespot

Originally created by @tweisberger on GitHub (Sep 5, 2022). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1057 **Describe the bug** When the audio device is removed while Spotify connected to `librespot` endpoint or when connect while audio interface is not present, `librespot` terminates. `librespot` should handle this gracefully. This requires manual intervention. This use case is using an external DAC connected to USB. When the DAC is set to another input away from USB, it removes the connection. Expected behavior would be to gracefully disconnect from Spotify. Or in the case where the audio device is not present, reject an incoming connection. **To reproduce** Steps to reproduce the behavior 1: _Audio interface is removed after connect: _ 1. Set DAC to USB input (connection the device running `librespot`). 2. Launch `librespot` with `sudo librespot --name Livingroom --bitrate 320 --format S16 --mixer softvol --initial-volume 70 --volume-ctrl log --volume-range 60 --autoplay --cache /var/local/www/spotify_cache --disable-audio-cache --backend alsa --device _audioout --onevent /var/local/www/commandw/spotevent.sh` 3. Connect with Spotify on iOS (or macOS) client 4. Change input of DAC away from USB 5. See error Behavior 2: _Audio interface is not present when connecting :_ 1. Set DAC to input other then USB. 2. Launch `librespot` with `sudo librespot --name Livingroom --bitrate 320 --format S16 --mixer softvol --initial-volume 70 --volume-ctrl log --volume-range 110 --autoplay --cache /var/local/www/spotify_cache --disable-audio-cache --backend alsa --device _audioout --onevent /var/local/www/commandw/spotevent.sh` 3. Connect with Spotify on iOS (or macOS) client 5. See error **Log** *Behavior 1 :* `[2022-08-31T22:09:38Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'EIO: I/O error' [2022-08-31T22:09:38Z ERROR librespot_playback::player] Audio Sink Error On Write: <AlsaSink> ALSA function 'snd_pcm_recover' failed with error 'EIO: I/O error' pi@moode:~ $` *Behavior 2:* `[2022-08-31T22:07:05Z TRACE librespot_playback::player] == Starting sink == ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card [2022-08-31T22:07:05Z ERROR librespot_playback::player] Audio Sink Error Connection Refused: <AlsaSink> Device _audioout May be Invalid, Busy, or Already in Use, ALSA function 'snd_pcm_open' failed with error 'ENOENT: No such file or directory' pi@moode:~ $` **Host** - Linux: 11.4 | 5.15.32-v8+ #1538 | aarch64 (64-bit) - moOde audio player 8.1.2 - librespot 0.4.1 88e64bd (Built on 2022-07-07, Build ID: jEVg9nf8, Profile: release) - Raspi: Pi-4B 1.5 2GB *Connecting Device* - SMSL DO100 USB DAC **Additional context** In the case of [moOde](https://github.com/moode-player/moode), `librespot` terminates, and the device becomes unusable until the user connects to the web ui and manually restarts `librespot`

kerem 2026-02-27 19:30:59 +03:00

• closed this issue
• added the
  bug
  label

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 8, 2022):

This is not a bug. This is a user/consumer error. It is up to moode to:

1. Make sure the device is available before allowing librespot to use it.

And

2. Handle services existing because of errors.

<!-- gh-comment-id:1241036713 --> @JasonLG1979 commented on GitHub (Sep 8, 2022): This is not a bug. This is a user/consumer error. It is up to moode to: 1. Make sure the device is available before allowing librespot to use it. And 2. Handle services existing because of errors.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 8, 2022):

Ok a further breakdown now that I'm home.

When the audio device is removed while Spotify connected to librespot endpoint or when connect while audio interface is not present, librespot terminates. librespot should handle this gracefully. This requires manual intervention.

In that case librespot logs an error message and exits with an exit status of 1 indicating an error. This is expected behavior.

This use case is using an external DAC connected to USB. When the DAC is set to another input away from USB, it removes the connection. Expected behavior would be to gracefully disconnect from Spotify. Or in the case where the audio device is not present, reject an incoming connection.

The same as above. On dev at least and possibly on master(?) librespot does disconnect from Spotify.

When librespot is not playing it closes the device and when it starts playing it tries to open the device. We do not monitor the status of devices we are not using and I'm unaware of any plans to do so.

There are blocking sink events you can subscribe to via an onevent script that will allow you to tell when librespot is about to try to open the device and/or has closed the device. In your onevent script you can do whatever you need to do to make sure the device you have told librespot to use actually exists and is available to use.

<!-- gh-comment-id:1241345808 --> @JasonLG1979 commented on GitHub (Sep 8, 2022): Ok a further breakdown now that I'm home. > When the audio device is removed while Spotify connected to librespot endpoint or when connect while audio interface is not present, librespot terminates. librespot should handle this gracefully. This requires manual intervention. In that case librespot logs an error message and exits with an exit status of 1 indicating an error. This is expected behavior. > This use case is using an external DAC connected to USB. When the DAC is set to another input away from USB, it removes the connection. Expected behavior would be to gracefully disconnect from Spotify. Or in the case where the audio device is not present, reject an incoming connection. The same as above. On `dev` at least and possibly on `master`(?) librespot does disconnect from Spotify. When librespot is not playing it closes the device and when it starts playing it tries to open the device. We do not monitor the status of devices we are not using and I'm unaware of any plans to do so. There are blocking sink events you can subscribe to via an onevent script that will allow you to tell when librespot is about to try to open the device and/or has closed the device. In your onevent script you can do whatever you need to do to make sure the device you have told librespot to use actually exists and is available to use.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 9, 2022):

You can use --emit-sink-events --onevent=path/to/my/script Events are sent as environment variables.

An example script:

#!/usr/bin/python3
import os

player_event = os.getenv('PLAYER_EVENT')

# The player thread will block until this script exits in all cases.
if player_event == 'sink':
    status = os.getenv('SINK_STATUS')
    if status == 'running':
        # The device is not open yet.
        # Do stuff to make sure the device you have told librespot
        # to use actually exists and is available to use.
        # The device will be opened after the script exits.
        print('The device is about to be opened.')
    elif status == 'temporarily_closed':
        # *Transient State* 
        # The device has been temporarily closed, for example librespot is loading.
        print('The device is closed, but more than likely will be reopened very shortly.')
    elif status == 'closed':
        # The device was closed before this script was called,
        # for example librespot is stopped or paused.
        # Other things are free to use the device after the script exits.
        print('The device has been closed.')

<!-- gh-comment-id:1241361120 --> @JasonLG1979 commented on GitHub (Sep 9, 2022): You can use `--emit-sink-events --onevent=path/to/my/script` Events are sent as environment variables. An example script: ```python3 #!/usr/bin/python3 import os player_event = os.getenv('PLAYER_EVENT') # The player thread will block until this script exits in all cases. if player_event == 'sink': status = os.getenv('SINK_STATUS') if status == 'running': # The device is not open yet. # Do stuff to make sure the device you have told librespot # to use actually exists and is available to use. # The device will be opened after the script exits. print('The device is about to be opened.') elif status == 'temporarily_closed': # *Transient State* # The device has been temporarily closed, for example librespot is loading. print('The device is closed, but more than likely will be reopened very shortly.') elif status == 'closed': # The device was closed before this script was called, # for example librespot is stopped or paused. # Other things are free to use the device after the script exits. print('The device has been closed.') ```

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (Sep 10, 2022):

Principally it is a fair use case as some good DACs indeed may turn off their USB circuitry when switched to another source, to minimize electrical noise.

However does this bug still happen if you stop Spotify first? Then switch input and back, start Spotify playback? From a code review I think that might work.

Otherwise on a failed write we could consider reopening the device one time only, then retry the write.

<!-- gh-comment-id:1242670124 --> @roderickvd commented on GitHub (Sep 10, 2022): Principally it is a fair use case as some good DACs indeed may turn off their USB circuitry when switched to another source, to minimize electrical noise. However does this bug still happen if you stop Spotify first? Then switch input and back, start Spotify playback? From a code review I think that might work. Otherwise on a failed write we could consider reopening the device one time only, then retry the write.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 10, 2022):

Principally it is a fair use case as some good DACs indeed may turn off their USB circuitry when switched to another source, to minimize electrical noise.

It's essentially the equivalent of unplugging a DAC during playback.

However does this bug still happen if you stop Spotify first? Then switch input and back, start Spotify playback? From a code review I think that might work.

If Spotify stops then librespot closes the device. But all these things happen asyc so you would have to stop well in advance to prevent player from pushing bytes to the device.

Otherwise on a failed write we could consider reopening the device one time only, then retry the write.

That's basically what try_recover in the ALSA Sink does. If we get the error in player it is fatal to the sink. What I can do is stop the sink and signal a disconnect from player. I just so happen to make that possible in my latest PR, but I still stand by my statement that it's not our responsibility to keep track of devices, that's the job of whatever daemonizes librespot. I will finish up the bits to make it work.

Currently the best thing for moode to do is just restart librespot when it happens. That's what systemd does and although it's not elegant it works fine.

<!-- gh-comment-id:1242739588 --> @JasonLG1979 commented on GitHub (Sep 10, 2022): > Principally it is a fair use case as some good DACs indeed may turn off their USB circuitry when switched to another source, to minimize electrical noise. It's essentially the equivalent of unplugging a DAC during playback. > However does this bug still happen if you stop Spotify first? Then switch input and back, start Spotify playback? From a code review I think that might work. If Spotify stops then librespot closes the device. But all these things happen asyc so you would have to stop well in advance to prevent player from pushing bytes to the device. > Otherwise on a failed write we could consider reopening the device one time only, then retry the write. That's basically what `try_recover` in the ALSA Sink does. If we get the error in player it is fatal to the sink. What I can do is stop the sink and signal a disconnect from player. I just so happen to make that possible in my latest PR, but I still stand by my statement that it's not our responsibility to keep track of devices, that's the job of whatever daemonizes librespot. I will finish up the bits to make it work. Currently the best thing for moode to do is just restart librespot when it happens. That's what systemd does and although it's not elegant it works fine.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (Sep 10, 2022):

That's basically what try_recover in the ALSA Sink does. If we get the error in player it is fatal to the sink. What I can do is stop the sink and signal a disconnect from player. I just so happen to make that possible in my latest PR, but I still stand by my statement that it's not our responsibility to keep track of devices, that's the job of whatever daemonizes librespot. I will finish up the bits to make it work.

I agree. If it's relatively easy though I guess it'd be a quick win.

<!-- gh-comment-id:1242772095 --> @roderickvd commented on GitHub (Sep 10, 2022): > That's basically what `try_recover` in the ALSA Sink does. If we get the error in player it is fatal to the sink. What I can do is stop the sink and signal a disconnect from player. I just so happen to make that possible in my latest PR, but I still stand by my statement that it's not our responsibility to keep track of devices, that's the job of whatever daemonizes librespot. I will finish up the bits to make it work. I agree. If it's relatively easy though I guess it'd be a quick win.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 10, 2022):

I got you one better. Instead of stopping and disconnecting I made it so that it just tells Spotify we're paused when the sink errors out.

So when a device disappears we just tell Spotify we're paused. While it's gone you can smash play all you want and you'll get a bunch of errors in the log but we won't exit or crash. After the device shows back up if you hit play it continues playback were you left off.

I tested it by unplugging and plugging my DAC and it seems to work pretty well.

<!-- gh-comment-id:1242781253 --> @JasonLG1979 commented on GitHub (Sep 10, 2022): I got you one better. Instead of stopping and disconnecting I made it so that it just tells Spotify we're paused when the sink errors out. So when a device disappears we just tell Spotify we're paused. While it's gone you can smash play all you want and you'll get a bunch of errors in the log but we won't exit or crash. After the device shows back up if you hit play it continues playback were you left off. I tested it by unplugging and plugging my DAC and it seems to work pretty well.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 10, 2022):

Basically the same thing will happen if a user tells librespot to use an invalid device. We won't exit or crash but you'll get a lot of errors and Spotify will just refuse to play no matter how hard you smash the play button.

<!-- gh-comment-id:1242782108 --> @JasonLG1979 commented on GitHub (Sep 10, 2022): Basically the same thing will happen if a user tells librespot to use an invalid device. We won't exit or crash but you'll get a lot of errors and Spotify will just refuse to play no matter how hard you smash the play button.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (Sep 10, 2022):

Great idea!

<!-- gh-comment-id:1242782423 --> @roderickvd commented on GitHub (Sep 10, 2022): Great idea!

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 10, 2022):

Ok I added it to that massive PR. Give it a test.

<!-- gh-comment-id:1242783211 --> @JasonLG1979 commented on GitHub (Sep 10, 2022): Ok I added it to that massive PR. Give it a test.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@JasonLG1979 commented on GitHub (Sep 10, 2022):

There is still no way currently to programmatically tell librespot to pause from the outside without using the spotify api though. I've got a REST style command API in the works so users and consumers can tell librespot to do basic commands. I'm thinking all POST's. Info would still be gotten from events.

<!-- gh-comment-id:1242785378 --> @JasonLG1979 commented on GitHub (Sep 10, 2022): There is still no way currently to programmatically tell librespot to pause from the outside without using the spotify api though. I've got a REST style command API in the works so users and consumers can tell librespot to do basic commands. I'm thinking all POST's. Info would still be gotten from events.

kerem commented 2026-02-27 19:30:59 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (Jan 14, 2023):

Closing this now I think that @JasonLG1979 made quite some effort on this a few months ago.

<!-- gh-comment-id:1382721111 --> @roderickvd commented on GitHub (Jan 14, 2023): Closing this now I think that @JasonLG1979 made quite some effort on this a few months ago.

kerem referenced this issue 2026-02-27 20:00:35 +03:00

[PR #501] [MERGED] Issue #497 - Playing songs from android app #950

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

dev

v0.8.0

v0.7.1

v0.7.0

v0.6.0

v0.5.0

v0.4.2

v0.4.1

v0.4.0

v0.3.1

v0.3.0

v0.2.0

v0.1.6

v0.1.5

v0.1.3

v0.1.2

v0.1.1

v0.1.0

Labels

Clear 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

Mirrored from GitHub Pull Request

  

question

  

reverse engineering

  

wiki

  

wontfix

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

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#497

No description provided.