starred/librespot
1
0
Fork 0
mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00
Code Issues 95 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #890] Rodio does not release the sound card #444

New issue
Closed
opened 2026-02-27 19:30:39 +03:00 by kerem · 7 comments
kerem commented 2026-02-27 19:30:39 +03:00
Owner
Copy link

Originally created by @Callenberg on GitHub (Nov 26, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/890

Originally assigned to: @roderickvd on GitHub.

Hello,
I have detected that the librespot child process that is associated with the sound card does not put the status of the card to "closed" as expected. Which means that librespot is blocking the sound card when another device is chosen and connected. This happens both for the Windows Spotify app and on my Android.

When checking the file /proc/asound/card0/pcm0p/sub0/status I can see that the running process persists: owner_pid : 5128. That is a child process to librespot according to the command pstree -p 5123 :

librespot(5123)─┬─{librespot}(5128)
                └─{librespot}(5129)

Work around: restart librespot, but in the long run that becomes a little bit tedious - I wonder what goes wrong? (The verbose output nor the journald gives me any clues.)

Version: librespot 0.3.1 UNKNOWN (Built on 2021-11-23, Build ID: 8hhgRK9U, Profile: release)
Installed with cargo install librespot and called with librespot -n Player -b 160 and also when librespot is a systemd service (using the librespot/contrib/librespot.user.service as a template).

the apt list command gives the following for the packages build-essential and libasound2-dev:

build-essential/oldstable,now 12.6 armhf [installed]
libasound2-dev/oldstable,now 1.1.8-1+rpt2 armhf [installed]

The linux version is Debian Buster: Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux

Thank you,
C

Originally created by @Callenberg on GitHub (Nov 26, 2021). Original GitHub issue: https://github.com/librespot-org/librespot/issues/890 Originally assigned to: @roderickvd on GitHub. Hello, I have detected that the librespot child process that is associated with the sound card does not put the status of the card to "closed" as expected. Which means that librespot is blocking the sound card when another device is chosen and connected. This happens both for the Windows Spotify app and on my Android. When checking the file `/proc/asound/card0/pcm0p/sub0/status` I can see that the running process persists: `owner_pid : 5128`. That is a child process to librespot according to the command `pstree -p 5123` : ``` librespot(5123)─┬─{librespot}(5128) └─{librespot}(5129) ``` **Work around:** restart librespot, but in the long run that becomes a little bit tedious - I wonder what goes wrong? (The verbose output nor the journald gives me any clues.) Version: `librespot 0.3.1 UNKNOWN (Built on 2021-11-23, Build ID: 8hhgRK9U, Profile: release)` Installed with `cargo install librespot` and called with `librespot -n Player -b 160 ` and also when librespot is a systemd service (using the `librespot/contrib/librespot.user.service` as a template). the `apt list` command gives the following for the packages build-essential and libasound2-dev: ``` build-essential/oldstable,now 12.6 armhf [installed] libasound2-dev/oldstable,now 1.1.8-1+rpt2 armhf [installed] ``` The linux version is Debian Buster: `Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux` Thank you, C
kerem 2026-02-27 19:30:39 +03:00
  • closed this issue
  • added the
    audio
         label
kerem commented 2026-02-27 19:30:40 +03:00
Author
Owner
Copy link

@roderickvd commented on GitHub (Nov 26, 2021):

Is this with Rodio or are you using --backend alsa? Please try that.

<!-- gh-comment-id:980301193 --> @roderickvd commented on GitHub (Nov 26, 2021): Is this with Rodio or are you using `--backend alsa`? Please try that.
kerem commented 2026-02-27 19:30:40 +03:00
Author
Owner
Copy link

@Callenberg commented on GitHub (Nov 26, 2021):

Thank you for the quick response.

I am using alsa and I realize now that I forgot that alsa is optional. However, adding --backend alsa made librespot panicking...
librespot -n Testing -b 160 --backend alsa caused the following:

[2021-11-26T22:19:33Z INFO  librespot] librespot 0.3.1 UNKNOWN (Built on 2021-11-23, Build ID: 8hhgRK9U, Profile: release)
thread 'main' panicked at 'Invalid backend', /root/.cargo/registry/src/github.com-1285ae84e5963aae/librespot-0.3.1/src/main.rs:462:53
stack backtrace:
   0:   0x8e314c - backtrace::backtrace::libunwind::trace::hae21a072c81e5842
                       at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1:   0x8e314c - backtrace::backtrace::trace_unsynchronized::h0f9b260087e46e47
                       at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2:   0x8e314c - std::sys_common::backtrace::_print_fmt::hbf1a59173a7860c3
                       at src/libstd/sys_common/backtrace.rs:78
   3:   0x8e314c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he1a5d6f378e506c4
                       at src/libstd/sys_common/backtrace.rs:59
   4:   0x9071d4 - core::fmt::write::hb37ae5a5e0b70623
                       at src/libcore/fmt/mod.rs:1076
   5:   0x8dc8d0 - std::io::Write::write_fmt::ha24bb3f5a858327b
                       at src/libstd/io/mod.rs:1537
   6:   0x8e5960 - std::sys_common::backtrace::_print::h47b03aa1342833e3
                       at src/libstd/sys_common/backtrace.rs:62
   7:   0x8e5960 - std::sys_common::backtrace::print::h2217cbc390250439
                       at src/libstd/sys_common/backtrace.rs:49
   8:   0x8e5960 - std::panicking::default_hook::{{closure}}::h179f5229ea1c8e30
                       at src/libstd/panicking.rs:198
   9:   0x8e562c - std::panicking::default_hook::h46ab82039cbc65eb
                       at src/libstd/panicking.rs:217
  10:   0x8e6040 - std::panicking::rust_panic_with_hook::h7326c48419bc7c33
                       at src/libstd/panicking.rs:526
  11:   0x8e5c40 - rust_begin_unwind
                       at src/libstd/panicking.rs:437
  12:   0x904a0c - core::panicking::panic_fmt::ha292e19d5ae716ed
                       at src/libcore/panicking.rs:85
  13:   0x9047e8 - core::option::expect_failed::he9e39f8f5ba60ecb
                       at src/libcore/option.rs:1261
  14:   0x4b666c - librespot::get_setup::h27fb6bf056796690
  15:   0x4877dc - librespot::main::{{closure}}::h0eb2c4bc153cc479
  16:   0x4bd8f4 - tokio::macros::scoped_tls::ScopedKey<T>::set::h2a73f4dfded1c303
  17:   0x52c944 - tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on::hf24be1171569aabb
  18:   0x4b7448 - librespot::main::h4b16a41319cbbaf7
  19:   0x51e2f8 - std::rt::lang_start::{{closure}}::h73d098fc528ae4c7
  20:   0x8e64f0 - std::rt::lang_start_internal::{{closure}}::he93bfc404849b78a
                       at src/libstd/rt.rs:52
  21:   0x8e64f0 - std::panicking::try::do_call::h6e9e98f4078affb0
                       at src/libstd/panicking.rs:348
  22:   0x8e64f0 - std::panicking::try::h2e68d4f7f799a6df
                       at src/libstd/panicking.rs:325
  23:   0x8e64f0 - std::panic::catch_unwind::h8880a4c07cc66391
                       at src/libstd/panic.rs:394
  24:   0x8e64f0 - std::rt::lang_start_internal::hf4ae2140248bf16b
                       at src/libstd/rt.rs:51
  25:   0x4b75ec - main
  26: 0xb6cda718 - __libc_start_main
                       at /build/glibc-FUvrFr/glibc-2.28/csu/libc-start.c:308

I must admit that I am new to rust and cargo so the bin file ended up in /root/.cargo/bin, maybe that is causing the trouble? (I thought it would be in /usr/bin/, ah, well I have to read more about cargo.)

<!-- gh-comment-id:980454031 --> @Callenberg commented on GitHub (Nov 26, 2021): Thank you for the quick response. I am using alsa and I realize now that I forgot that alsa is optional. However, adding `--backend alsa ` made librespot panicking... `librespot -n Testing -b 160 --backend alsa` caused the following: ``` [2021-11-26T22:19:33Z INFO librespot] librespot 0.3.1 UNKNOWN (Built on 2021-11-23, Build ID: 8hhgRK9U, Profile: release) thread 'main' panicked at 'Invalid backend', /root/.cargo/registry/src/github.com-1285ae84e5963aae/librespot-0.3.1/src/main.rs:462:53 stack backtrace: 0: 0x8e314c - backtrace::backtrace::libunwind::trace::hae21a072c81e5842 at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86 1: 0x8e314c - backtrace::backtrace::trace_unsynchronized::h0f9b260087e46e47 at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66 2: 0x8e314c - std::sys_common::backtrace::_print_fmt::hbf1a59173a7860c3 at src/libstd/sys_common/backtrace.rs:78 3: 0x8e314c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he1a5d6f378e506c4 at src/libstd/sys_common/backtrace.rs:59 4: 0x9071d4 - core::fmt::write::hb37ae5a5e0b70623 at src/libcore/fmt/mod.rs:1076 5: 0x8dc8d0 - std::io::Write::write_fmt::ha24bb3f5a858327b at src/libstd/io/mod.rs:1537 6: 0x8e5960 - std::sys_common::backtrace::_print::h47b03aa1342833e3 at src/libstd/sys_common/backtrace.rs:62 7: 0x8e5960 - std::sys_common::backtrace::print::h2217cbc390250439 at src/libstd/sys_common/backtrace.rs:49 8: 0x8e5960 - std::panicking::default_hook::{{closure}}::h179f5229ea1c8e30 at src/libstd/panicking.rs:198 9: 0x8e562c - std::panicking::default_hook::h46ab82039cbc65eb at src/libstd/panicking.rs:217 10: 0x8e6040 - std::panicking::rust_panic_with_hook::h7326c48419bc7c33 at src/libstd/panicking.rs:526 11: 0x8e5c40 - rust_begin_unwind at src/libstd/panicking.rs:437 12: 0x904a0c - core::panicking::panic_fmt::ha292e19d5ae716ed at src/libcore/panicking.rs:85 13: 0x9047e8 - core::option::expect_failed::he9e39f8f5ba60ecb at src/libcore/option.rs:1261 14: 0x4b666c - librespot::get_setup::h27fb6bf056796690 15: 0x4877dc - librespot::main::{{closure}}::h0eb2c4bc153cc479 16: 0x4bd8f4 - tokio::macros::scoped_tls::ScopedKey<T>::set::h2a73f4dfded1c303 17: 0x52c944 - tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on::hf24be1171569aabb 18: 0x4b7448 - librespot::main::h4b16a41319cbbaf7 19: 0x51e2f8 - std::rt::lang_start::{{closure}}::h73d098fc528ae4c7 20: 0x8e64f0 - std::rt::lang_start_internal::{{closure}}::he93bfc404849b78a at src/libstd/rt.rs:52 21: 0x8e64f0 - std::panicking::try::do_call::h6e9e98f4078affb0 at src/libstd/panicking.rs:348 22: 0x8e64f0 - std::panicking::try::h2e68d4f7f799a6df at src/libstd/panicking.rs:325 23: 0x8e64f0 - std::panic::catch_unwind::h8880a4c07cc66391 at src/libstd/panic.rs:394 24: 0x8e64f0 - std::rt::lang_start_internal::hf4ae2140248bf16b at src/libstd/rt.rs:51 25: 0x4b75ec - main 26: 0xb6cda718 - __libc_start_main at /build/glibc-FUvrFr/glibc-2.28/csu/libc-start.c:308 ``` I must admit that I am new to rust and cargo so the bin file ended up in /root/.cargo/bin, maybe that is causing the trouble? (I thought it would be in /usr/bin/, ah, well I have to read more about cargo.)
kerem commented 2026-02-27 19:30:40 +03:00
Author
Owner
Copy link

@roderickvd commented on GitHub (Nov 26, 2021):

Please refer to the wiki and COMPILING.md. It's all documented.

<!-- gh-comment-id:980465986 --> @roderickvd commented on GitHub (Nov 26, 2021): Please refer to the [wiki](https://github.com/librespot-org/librespot/wiki) and [COMPILING.md](https://github.com/librespot-org/librespot/blob/dev/COMPILING.md). It's all documented.
kerem commented 2026-02-27 19:30:40 +03:00
Author
Owner
Copy link

@Callenberg commented on GitHub (Nov 27, 2021):

Will do that!, thank you!

<!-- gh-comment-id:980643538 --> @Callenberg commented on GitHub (Nov 27, 2021): Will do that!, thank you!
kerem commented 2026-02-27 19:30:40 +03:00
Author
Owner
Copy link

@JasonLG1979 commented on GitHub (Nov 28, 2021):

@Callenberg if you're planning on using librespot on a headless Pi you might checkout Raspotify although I can't guarantee Buster compatibility. You'll probably need to upgrade to Bullseye.

My plan is to keep Raspotify up to date with librespot's dev branch. So really unless you plan on being a librespot dev it's the way to go IMHO. I may be a little biased though 😉 being one of it's maintainers.

<!-- gh-comment-id:980838203 --> @JasonLG1979 commented on GitHub (Nov 28, 2021): @Callenberg if you're planning on using `librespot` on a headless Pi you might checkout [Raspotify](https://github.com/dtcooper/raspotify) although I can't guarantee Buster compatibility. You'll probably need to upgrade to Bullseye. My plan is to keep Raspotify up to date with `librespot`'s dev branch. So really unless you plan on being a `librespot` dev it's the way to go IMHO. I may be a little biased though :wink: being one of it's maintainers.
kerem commented 2026-02-27 19:30:40 +03:00
Author
Owner
Copy link

@Callenberg commented on GitHub (Nov 28, 2021):

Thank you for the tip!

The only reason I hesitate to upgrade to Bullseye is that I want to be able to use bluealsa (alsa for Bluetooth) and that package is not a part of the distro anymore. I thought it was time to update librespot on my Raspberry and I maybe building librespot myself might be an easier way (and avoid Bullseye for the time being). I understand what you are saying - I will check out Raspotify some more for sure. Thanks.

<!-- gh-comment-id:981164396 --> @Callenberg commented on GitHub (Nov 28, 2021): Thank you for the tip! The only reason I hesitate to upgrade to Bullseye is that I want to be able to use bluealsa (alsa for Bluetooth) and that package is not a part of the distro anymore. I thought it was time to update librespot on my Raspberry and I maybe building librespot myself might be an easier way (and avoid Bullseye for the time being). I understand what you are saying - I will check out Raspotify some more for sure. Thanks.
kerem commented 2026-02-27 19:30:40 +03:00
Author
Owner
Copy link

@JasonLG1979 commented on GitHub (Nov 28, 2021):

bluealsa (alsa for Bluetooth)

Yes I'm familiar

that package is not a part of the distro anymore.

It looks like it will back in the bluez-alsa-utils package in the next Debian release.

<!-- gh-comment-id:981171467 --> @JasonLG1979 commented on GitHub (Nov 28, 2021): > bluealsa (alsa for Bluetooth) Yes [I'm familiar](https://github.com/JasonLG1979/PiZero-Bluetooth-Audio-Receiver) > that package is not a part of the distro anymore. It looks like it will back in the `bluez-alsa-utils` package in the next Debian release.
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
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#444
No description provided.