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

[GH-ISSUE #1546] librespot fails to accept ALSA device names as an output device #699

New issue
Open
opened 2026-02-27 19:32:01 +03:00 by kerem · 9 comments
kerem commented 2026-02-27 19:32:01 +03:00
Owner
Copy link

Originally created by @jduncanator on GitHub (Aug 22, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1546

Originally assigned to: @roderickvd on GitHub.

Description

Since commit ce1ab8ff3f, the Rodio backend no longer exposes or recognizes ALSA device names, and instead only lists and recognizes "friendly names" for ALSA outputs.

After this commit the output of librespot --device ? is the following:

[2025-08-21T06:39:33Z INFO  librespot] librespot 0.6.0-dev c4766ce (Built on 2025-08-21, Build ID: QpLfXiGR, Profile: release)
[2025-08-21T06:39:33Z INFO  librespot_playback::audio_backend::rodio] Using Rodio sink with format S16 and cpal host: ALSA
Default Audio Device:
  default
Other Available Audio Devices:
  HDA Intel PCH
  Merging RAVENNA

Prior to this commit the output is the following:

[2025-08-21T06:32:04Z INFO  librespot] librespot 0.6.0-dev be37402 (Built on 2025-08-21, Build ID: HgoztJtj, Profile: release)
[2025-08-21T06:32:04Z INFO  librespot_playback::audio_backend::rodio] Using Rodio sink with format S16 and cpal host: ALSA
Default Audio Device:
  default
Other Available Audio Devices:
  hw:CARD=PCH,DEV=0
  hw:CARD=PCH,DEV=3
  hw:CARD=PCH,DEV=7
  hw:CARD=PCH,DEV=8
  hw:CARD=PCH,DEV=9
  plughw:CARD=PCH,DEV=0
  plughw:CARD=PCH,DEV=3
  plughw:CARD=PCH,DEV=7
  plughw:CARD=PCH,DEV=8
  plughw:CARD=PCH,DEV=9
  default:CARD=PCH
  sysdefault:CARD=PCH
  front:CARD=PCH,DEV=0
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
  surround40:CARD=PCH,DEV=0
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
  surround51:CARD=PCH,DEV=0
  surround71:CARD=PCH,DEV=0
  hdmi:CARD=PCH,DEV=0
  hdmi:CARD=PCH,DEV=1
  hdmi:CARD=PCH,DEV=2
  hdmi:CARD=PCH,DEV=3
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
  dmix:CARD=PCH,DEV=0
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
  dmix:CARD=PCH,DEV=3
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
  dmix:CARD=PCH,DEV=7
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
  dmix:CARD=PCH,DEV=8
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
  dmix:CARD=PCH,DEV=9
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
  hw:CARD=RAVENNA,DEV=0
  plughw:CARD=RAVENNA,DEV=0
  default:CARD=RAVENNA
  sysdefault:CARD=RAVENNA
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
  dmix:CARD=RAVENNA,DEV=0
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream

When attempting to run librespot with an ALSA device (ie. librespot --device dmix:CARD=RAVENNA,DEV=0), the output is as a following:

[2025-08-21T05:59:52Z INFO  librespot_playback::audio_backend::rodio] Using Rodio sink with format S24_3 and cpal host: ALSA
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pipewire
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pipewire
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pulse
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pulse
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM jack
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM jack
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM oss
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM oss

thread '<unnamed>' panicked at playback/src/audio_backend/rodio.rs:219:61:
called `Result::unwrap()` on an `Err` value: DeviceNotAvailable("hw:CARD=RAVENNA,DEV=0")
stack backtrace:
   0:     0x55e507195d79 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hc27021c40099767c
   1:     0x55e5071aa0a3 - core::fmt::write::h4f0770298adcd782
   2:     0x55e507184cff - std::io::Write::write_fmt::h0b2c201fcd300be4
   3:     0x55e507195bc3 - std::sys::backtrace::BacktraceLock::print::hbd491c8a45546b91
   4:     0x55e507160f45 - std::panicking::default_hook::{{closure}}::h65f4a8f2e434ce09
   5:     0x55e507160d38 - std::panicking::default_hook::h73ef68af6ebbb2d3
   6:     0x55e50716151f - std::panicking::rust_panic_with_hook::h1c95e5ef3e82efd3
   7:     0x55e50719684a - std::panicking::begin_panic_handler::{{closure}}::h4ba25af490254d55
   8:     0x55e507195fa9 - std::sys::backtrace::__rust_end_short_backtrace::hcd9c5798c8bf2e2a
   9:     0x55e50716108d - rust_begin_unwind
  10:     0x55e50693f5f0 - core::panicking::panic_fmt::h96856782d9d1734f
  11:     0x55e50693fb76 - core::result::unwrap_failed::hbbe143ff7eea6e77
  12:     0x55e506bcbcc0 - librespot_playback::audio_backend::rodio::mk_rodio::h0733a9a4505391cb
  13:     0x55e506a3c7b1 - std::sys::backtrace::__rust_begin_short_backtrace::hc5c44d38822e029f
  14:     0x55e506a3da4f - core::ops::function::FnOnce::call_once{{vtable.shim}}::hc3eead36c5fb2b9d
  15:     0x55e507161b6b - std::sys::pal::unix::thread::Thread::new::thread_start::hcbb8fcac760f1b8f
  16:     0x7fb15e1acb7b - start_thread
                               at ./nptl/pthread_create.c:448:8
  17:     0x7fb15e22a7b8 - __GI___clone3
                               at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
  18:                0x0 - <unknown>

Version

Versions since commit ce1ab8ff3f

How to reproduce

Steps to reproduce the behavior in librespot e.g.

  1. Launch librespot with '--devices ?'
  2. Observe the lack of ALSA backend devices in the list

Host (what you are running librespot on):

  • OS: Debian Trixie, Linux 6.12.41

Additional context

This significantly impacts our ability to use librespot. We run multiple instances, that output to multiple sub-devices of a parent device, and we can no longer target these ALSA devices.

Originally created by @jduncanator on GitHub (Aug 22, 2025). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1546 Originally assigned to: @roderickvd on GitHub. ### Description Since commit ce1ab8ff3fb9d4bcac461307c0233ef732463084, the Rodio backend no longer exposes or recognizes ALSA device names, and instead only lists and recognizes "friendly names" for ALSA outputs. After this commit the output of `librespot --device ?` is the following: ``` [2025-08-21T06:39:33Z INFO librespot] librespot 0.6.0-dev c4766ce (Built on 2025-08-21, Build ID: QpLfXiGR, Profile: release) [2025-08-21T06:39:33Z INFO librespot_playback::audio_backend::rodio] Using Rodio sink with format S16 and cpal host: ALSA Default Audio Device: default Other Available Audio Devices: HDA Intel PCH Merging RAVENNA ``` Prior to this commit the output is the following: ``` [2025-08-21T06:32:04Z INFO librespot] librespot 0.6.0-dev be37402 (Built on 2025-08-21, Build ID: HgoztJtj, Profile: release) [2025-08-21T06:32:04Z INFO librespot_playback::audio_backend::rodio] Using Rodio sink with format S16 and cpal host: ALSA Default Audio Device: default Other Available Audio Devices: hw:CARD=PCH,DEV=0 hw:CARD=PCH,DEV=3 hw:CARD=PCH,DEV=7 hw:CARD=PCH,DEV=8 hw:CARD=PCH,DEV=9 plughw:CARD=PCH,DEV=0 plughw:CARD=PCH,DEV=3 plughw:CARD=PCH,DEV=7 plughw:CARD=PCH,DEV=8 plughw:CARD=PCH,DEV=9 default:CARD=PCH sysdefault:CARD=PCH front:CARD=PCH,DEV=0 ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map surround40:CARD=PCH,DEV=0 ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map surround51:CARD=PCH,DEV=0 surround71:CARD=PCH,DEV=0 hdmi:CARD=PCH,DEV=0 hdmi:CARD=PCH,DEV=1 hdmi:CARD=PCH,DEV=2 hdmi:CARD=PCH,DEV=3 ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream dmix:CARD=PCH,DEV=0 ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream dmix:CARD=PCH,DEV=3 ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream dmix:CARD=PCH,DEV=7 ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream dmix:CARD=PCH,DEV=8 ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream dmix:CARD=PCH,DEV=9 ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream hw:CARD=RAVENNA,DEV=0 plughw:CARD=RAVENNA,DEV=0 default:CARD=RAVENNA sysdefault:CARD=RAVENNA ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream dmix:CARD=RAVENNA,DEV=0 ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ``` When attempting to run librespot with an ALSA device (ie. `librespot --device dmix:CARD=RAVENNA,DEV=0`), the output is as a following: ``` [2025-08-21T05:59:52Z INFO librespot_playback::audio_backend::rodio] Using Rodio sink with format S24_3 and cpal host: ALSA ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pipewire ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pipewire ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pulse ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM pulse ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM jack ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM jack ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM oss ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM oss thread '<unnamed>' panicked at playback/src/audio_backend/rodio.rs:219:61: called `Result::unwrap()` on an `Err` value: DeviceNotAvailable("hw:CARD=RAVENNA,DEV=0") stack backtrace: 0: 0x55e507195d79 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hc27021c40099767c 1: 0x55e5071aa0a3 - core::fmt::write::h4f0770298adcd782 2: 0x55e507184cff - std::io::Write::write_fmt::h0b2c201fcd300be4 3: 0x55e507195bc3 - std::sys::backtrace::BacktraceLock::print::hbd491c8a45546b91 4: 0x55e507160f45 - std::panicking::default_hook::{{closure}}::h65f4a8f2e434ce09 5: 0x55e507160d38 - std::panicking::default_hook::h73ef68af6ebbb2d3 6: 0x55e50716151f - std::panicking::rust_panic_with_hook::h1c95e5ef3e82efd3 7: 0x55e50719684a - std::panicking::begin_panic_handler::{{closure}}::h4ba25af490254d55 8: 0x55e507195fa9 - std::sys::backtrace::__rust_end_short_backtrace::hcd9c5798c8bf2e2a 9: 0x55e50716108d - rust_begin_unwind 10: 0x55e50693f5f0 - core::panicking::panic_fmt::h96856782d9d1734f 11: 0x55e50693fb76 - core::result::unwrap_failed::hbbe143ff7eea6e77 12: 0x55e506bcbcc0 - librespot_playback::audio_backend::rodio::mk_rodio::h0733a9a4505391cb 13: 0x55e506a3c7b1 - std::sys::backtrace::__rust_begin_short_backtrace::hc5c44d38822e029f 14: 0x55e506a3da4f - core::ops::function::FnOnce::call_once{{vtable.shim}}::hc3eead36c5fb2b9d 15: 0x55e507161b6b - std::sys::pal::unix::thread::Thread::new::thread_start::hcbb8fcac760f1b8f 16: 0x7fb15e1acb7b - start_thread at ./nptl/pthread_create.c:448:8 17: 0x7fb15e22a7b8 - __GI___clone3 at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 18: 0x0 - <unknown> ``` ### Version Versions since commit ce1ab8ff3fb9d4bcac461307c0233ef732463084 ### How to reproduce Steps to reproduce the behavior in *librespot* e.g. 1. Launch `librespot` with '--devices ?' 2. Observe the lack of ALSA backend devices in the list ### Host (what you are running `librespot` on): - OS: Debian Trixie, Linux 6.12.41 ### Additional context This significantly impacts our ability to use librespot. We run multiple instances, that output to multiple sub-devices of a parent device, and we can no longer target these ALSA devices.
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@jduncanator commented on GitHub (Aug 22, 2025):

Suspect this was broken in cpal here: github.com/RustAudio/cpal@f43d36e554.

<!-- gh-comment-id:3212557265 --> @jduncanator commented on GitHub (Aug 22, 2025): Suspect this was broken in cpal here: https://github.com/RustAudio/cpal/commit/f43d36e55494993bbbde3299af0c53e5cdf4d4cf.
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@jduncanator commented on GitHub (Aug 22, 2025):

I can confirm, manually reverting github.com/RustAudio/cpal@f43d36e554 from cpal, and referencing a local version of the dependency resolves this issue. Not sure how best to proceed with getting 0.7.0 out, however I feel like this will be a fairly significant breaking change for a lot of people downstream.

The quickest way would be to revert cpal and rodio back to 0.15.1/0.20.1, but I'm aware there are a number of changes in the change-log that depend on the dep bump of Rodio.

[2025-08-22T00:46:12Z INFO  librespot] librespot 0.6.0-dev 78ce118 (Built on 2025-08-22, Build ID: 2GkhTSp9, Profile: release)
[2025-08-22T00:46:12Z INFO  librespot_playback::mixer::softmixer] Mixing with softvol and volume control: Log(60.0)
[2025-08-22T00:46:12Z INFO  librespot_playback::audio_backend::rodio] Using Rodio sink with format S32 and cpal host: ALSA
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
[2025-08-22T00:46:12Z INFO  librespot_playback::audio_backend::rodio] Using audio device: plughw:CARD=RAVENNA,DEV=0
<!-- gh-comment-id:3212576190 --> @jduncanator commented on GitHub (Aug 22, 2025): I can confirm, manually reverting https://github.com/RustAudio/cpal/commit/f43d36e55494993bbbde3299af0c53e5cdf4d4cf from cpal, and referencing a local version of the dependency resolves this issue. Not sure how best to proceed with getting 0.7.0 out, however I feel like this will be a fairly significant breaking change for a lot of people downstream. The quickest way would be to revert cpal and rodio back to 0.15.1/0.20.1, but I'm aware there are a number of changes in the change-log that depend on the dep bump of Rodio. ``` [2025-08-22T00:46:12Z INFO librespot] librespot 0.6.0-dev 78ce118 (Built on 2025-08-22, Build ID: 2GkhTSp9, Profile: release) [2025-08-22T00:46:12Z INFO librespot_playback::mixer::softmixer] Mixing with softvol and volume control: Log(60.0) [2025-08-22T00:46:12Z INFO librespot_playback::audio_backend::rodio] Using Rodio sink with format S32 and cpal host: ALSA ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream ALSA lib pcm_dmix.c:973:(snd_pcm_dmix_open) The dmix plugin supports only playback stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream ALSA lib pcm_dsnoop.c:541:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream [2025-08-22T00:46:12Z INFO librespot_playback::audio_backend::rodio] Using audio device: plughw:CARD=RAVENNA,DEV=0 ```
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@jduncanator commented on GitHub (Aug 22, 2025):

Looks like @roderickvd is already on it, didn't look close enough at the cpal repo. Relevant issues and PRs here: https://github.com/RustAudio/cpal/issues/991 https://github.com/RustAudio/cpal/pull/992.

We should look to apply their fix as a patch until this is fixed upstream: github.com/roderickvd/pleezer@f16802aaf9

<!-- gh-comment-id:3212591806 --> @jduncanator commented on GitHub (Aug 22, 2025): Looks like @roderickvd is already on it, didn't look close enough at the cpal repo. Relevant issues and PRs here: https://github.com/RustAudio/cpal/issues/991 https://github.com/RustAudio/cpal/pull/992. We should look to apply their fix as a patch until this is fixed upstream: https://github.com/roderickvd/pleezer/commit/f16802aaf94f6f5ff44b5167c817283a7795cc8d
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@roderickvd commented on GitHub (Aug 22, 2025):

Thanks for reporting. Yes, known. Let’s continue the technical discussion over at the cpal PR.

For librespot, rather than rolling back now I prefer that users use the dedicated Alsa backend instead.

For the normal use case, Rodio in librespot is still able to open the default Alsa device. If you must use Rodio instead of Alsa (why? 😄 ) then you can work around this by creating an asoundrc and forward the default device to what you want.

<!-- gh-comment-id:3213289348 --> @roderickvd commented on GitHub (Aug 22, 2025): Thanks for reporting. Yes, known. Let’s continue the technical discussion over at the cpal PR. For librespot, rather than rolling back now I prefer that users use the dedicated Alsa backend instead. For the normal use case, Rodio in librespot is still able to open the default Alsa device. If you _must_ use Rodio instead of Alsa (why? 😄 ) then you can work around this by creating an `asoundrc` and forward the default device to what you want.
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@roderickvd commented on GitHub (Aug 22, 2025):

Over at the cpal I thought I had seen a comment of yours with a very interesting data point, but I can’t find it anymore. Could you re-add there your experience with dmix:CARD=RAVENNA,DEV=0 and add what’s special about it? What kind of device is it, how was it set up?

<!-- gh-comment-id:3213342860 --> @roderickvd commented on GitHub (Aug 22, 2025): Over at the cpal I thought I had seen a comment of yours with a very interesting data point, but I can’t find it anymore. Could you re-add there your experience with `dmix:CARD=RAVENNA,DEV=0` and add what’s special about it? What kind of device is it, how was it set up?
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@jduncanator commented on GitHub (Aug 22, 2025):

Over at the cpal I thought I had seen a comment of yours with a very interesting data point, but I can’t find it anymore. Could you re-add there your experience with dmix:CARD=RAVENNA,DEV=0 and add what’s special about it? What kind of device is it, how was it set up?

I did make an initial note that it appeared with the fix in your PR the Ravenna device didn't appear in the device list, however it was due to the device being open (with plughw) in another instance of librespot, and not due to an issue with the PR itself. I removed the comment after I realized the PR worked correctly.

For context, the Ravenna device is an AES67 virtual sound card, source here: https://bitbucket.org/MergingTechnologies/ravenna-alsa-lkm

Thanks for reporting. Yes, known. Let’s continue the technical discussion over at the cpal PR.

For librespot, rather than rolling back now I prefer that users use the dedicated Alsa backend instead.

For the normal use case, Rodio in librespot is still able to open the default Alsa device. If you must use Rodio instead of Alsa (why? 😄 ) then you can work around this by creating an asoundrc and forward the default device to what you want.

I'm happy to use the ALSA backend directly, to be honest I wasn't even aware it existed until I started troubleshooting this issue. I've always used the default Rodio backend by default.

<!-- gh-comment-id:3213357001 --> @jduncanator commented on GitHub (Aug 22, 2025): > Over at the cpal I thought I had seen a comment of yours with a very interesting data point, but I can’t find it anymore. Could you re-add there your experience with `dmix:CARD=RAVENNA,DEV=0` and add what’s special about it? What kind of device is it, how was it set up? I did make an initial note that it appeared with the fix in your PR the Ravenna device didn't appear in the device list, however it was due to the device being open (with `plughw`) in another instance of librespot, and not due to an issue with the PR itself. I removed the comment after I realized the PR worked correctly. For context, the Ravenna device is an AES67 virtual sound card, source here: https://bitbucket.org/MergingTechnologies/ravenna-alsa-lkm > Thanks for reporting. Yes, known. Let’s continue the technical discussion over at the cpal PR. > > For librespot, rather than rolling back now I prefer that users use the dedicated Alsa backend instead. > > For the normal use case, Rodio in librespot is still able to open the default Alsa device. If you _must_ use Rodio instead of Alsa (why? 😄 ) then you can work around this by creating an `asoundrc` and forward the default device to what you want. I'm happy to use the ALSA backend directly, to be honest I wasn't even aware it existed until I started troubleshooting this issue. I've always used the default Rodio backend by default.
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@roderickvd commented on GitHub (Aug 22, 2025):

Over at the cpal I thought I had seen a comment of yours with a very interesting data point, but I can’t find it anymore. Could you re-add there your experience with dmix:CARD=RAVENNA,DEV=0 and add what’s special about it? What kind of device is it, how was it set up?

I did make an initial note that it appeared with the fix in your PR the Ravenna device didn't appear in the device list, however it was due to the device being open (with plughw) in another instance of librespot, and not due to an issue with the PR itself.

I see. In this exact condition of already being opened, did it enumerate with cpal 0.15?

I'm happy to use the ALSA backend directly, to be honest I wasn't even aware it existed until I started troubleshooting this issue. I've always used the default Rodio backend by default.

Cool. Rodio is there for ease of use, but Alsa is more bare metal.

<!-- gh-comment-id:3213401679 --> @roderickvd commented on GitHub (Aug 22, 2025): > > Over at the cpal I thought I had seen a comment of yours with a very interesting data point, but I can’t find it anymore. Could you re-add there your experience with `dmix:CARD=RAVENNA,DEV=0` and add what’s special about it? What kind of device is it, how was it set up? > > I did make an initial note that it appeared with the fix in your PR the Ravenna device didn't appear in the device list, however it was due to the device being open (with `plughw`) in another instance of librespot, and not due to an issue with the PR itself. I see. In this exact condition of already being opened, did it enumerate with cpal 0.15? > I'm happy to use the ALSA backend directly, to be honest I wasn't even aware it existed until I started troubleshooting this issue. I've always used the default Rodio backend by default. Cool. Rodio is there for ease of use, but Alsa is more bare metal.
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@jduncanator commented on GitHub (Aug 22, 2025):

I see. In this exact condition of already being opened, did it enumerate with cpal 0.15?

I've tested this, and the behavior is the same between both versions.

<!-- gh-comment-id:3213622083 --> @jduncanator commented on GitHub (Aug 22, 2025): > I see. In this exact condition of already being opened, did it enumerate with cpal 0.15? I've tested this, and the behavior is the same between both versions.
kerem commented 2026-02-27 19:32:02 +03:00
Author
Owner
Copy link

@jduncanator commented on GitHub (Oct 24, 2025):

For what it's worth, I've switched back to cpal, with a patch applied to librespot to grab the latest upstream, because I ran into weird issues with using ALSA directly that I didn't using cpal. Over time, I get increasingly worse and worse distortion, playback rate warping, and eventually audibly dropped samples. I've noticed since switching to the ALSA backend I get a multitude of error messages that look like the following:

[2025-10-24T10:17:22Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)'
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
[2025-10-24T10:17:22Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)'
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
[2025-10-24T10:17:22Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)'
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
[2025-10-24T10:17:22Z WARN  librespot_playback::player] This track may exceed dBFS by 1.18 dB and be subject to 3.18 dB of dynamic limiting at its peak.
[2025-10-24T10:17:22Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)'
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
[2025-10-24T10:18:31Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)'
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
[2025-10-24T10:18:33Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)'
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred

Regardless, just reporting that the change to cpal has fixed this issue for me, and looking forward to it landing in the latest version of librespot.

<!-- gh-comment-id:3442443769 --> @jduncanator commented on GitHub (Oct 24, 2025): For what it's worth, I've switched back to cpal, with a patch applied to librespot to grab the latest upstream, because I ran into weird issues with using ALSA directly that I didn't using cpal. Over time, I get increasingly worse and worse distortion, playback rate warping, and eventually audibly dropped samples. I've noticed since switching to the ALSA backend I get a multitude of error messages that look like the following: ``` [2025-10-24T10:17:22Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)' ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred [2025-10-24T10:17:22Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)' ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred [2025-10-24T10:17:22Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)' ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred [2025-10-24T10:17:22Z WARN librespot_playback::player] This track may exceed dBFS by 1.18 dB and be subject to 3.18 dB of dynamic limiting at its peak. [2025-10-24T10:17:22Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)' ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred [2025-10-24T10:18:31Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)' ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred [2025-10-24T10:18:33Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)' ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred ``` Regardless, just reporting that the change to cpal has fixed this issue for me, and looking forward to it landing in the latest version of librespot.
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#699
No description provided.