[GH-ISSUE #320] Music Continues to Go Through The Speakers Despite Despite The Presence of Bluetooth Headphones

kerem commented

2026-03-14 13:28:09 +03:00

Owner

Originally created by @nathan-2006 on GitHub (Dec 17, 2023).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/320

Describe the bug

Audio does not go through Bluetooth headphones despite it being the default audio device and all other sounds playing through the Bluetooth device. The "RestartIntegratedClient" and "RefreshPlayback" tools do not resolve the problem. This was tested with Spotify_Player being built with the 'rodio-backend' and 'alsa-backend' on 0.16.1 and 'rodio-backend' on 0.16.2

To Reproduce

Pair a Bluetooth device, launch Spotify_Player, and try playing a song.

Expected behavior

Audio successfully playing through the paired Bluetooth deveice.

Log and backtrace
Reference log and backtrace, which are usually located in $HOME/.cache/spotify-player/, of a run reproducing the bug.

The backtrace log is empty with first try on 0.16.1 but on 0.16.2 with trying to get it to work did I get a "No playback devices" error with trying "RestartIntegratedClient" and "RefreshPlayback" once or a few times. That produced a proper backtrace log:

Got a panic: PanicInfo {
    payload: Any { .. },
    message: Some(
        called `Result::unwrap()` on an `Err` value: StreamError(DefaultStreamConfigError(DeviceNotAvailable)),
    ),
    location: Location {
        file: "/home/nathan/.cargo/registry/src/index.crates.io-1cd66030c949c28d/librespot-playback-0.4.2/src/audio_backend/rodio.rs",
        line: 178,
        col: 53,
    },
    can_unwind: true,
    force_no_backtrace: false,
}

Stack backtrace:
   0: backtrace::capture::Backtrace::new
   1: spotify_player::init_logging::{{closure}}
   2: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/alloc/src/boxed.rs:2021:9
      std::panicking::rust_panic_with_hook
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:735:13
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:609:13
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/sys_common/backtrace.rs:170:18
   5: rust_begin_unwind
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:597:5
   6: core::panicking::panic_fmt
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/panicking.rs:72:14
   7: core::result::unwrap_failed
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/result.rs:1652:5
   8: librespot_playback::audio_backend::rodio::mk_rodio
   9: std::sys_common::backtrace::__rust_begin_short_backtrace
  10: core::ops::function::FnOnce::call_once{{vtable.shim}}
  11: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/alloc/src/boxed.rs:2007:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/alloc/src/boxed.rs:2007:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/sys/unix/thread.rs:108:17

Environment

OS: Ubuntu Noble 24.04 LTS (Development Branch)
Application version: 0.16.1 for when 'alsa-backend' was tested and 'rodio-backend' for both 0.16.2 and 0.16.1 (so it appears that there that this issue is still present on 0.16.2)
Application features: if applicable, provide cargo features used to build spotify_player

Default settings apart from the one instance from when the backend being changed to 'alsa-backend' in which the application was built with '--no-default-features --features alsa-backend'

Additional context

It's highly unlikely that this is something that relates to my device's architecture, but the device Spotify_Player is being used on is an ARMv7h device. I also used Clang as the compiler.

Originally created by @nathan-2006 on GitHub (Dec 17, 2023). Original GitHub issue: https://github.com/aome510/spotify-player/issues/320 **Describe the bug** Audio does not go through Bluetooth headphones despite it being the default audio device and all other sounds playing through the Bluetooth device. The "RestartIntegratedClient" and "RefreshPlayback" tools do not resolve the problem. This was tested with Spotify_Player being built with the 'rodio-backend' and 'alsa-backend' on 0.16.1 and 'rodio-backend' on 0.16.2 **To Reproduce** Pair a Bluetooth device, launch Spotify_Player, and try playing a song. **Expected behavior** Audio successfully playing through the paired Bluetooth deveice. **Log and backtrace** Reference log and backtrace, which are usually located in `$HOME/.cache/spotify-player/`, of a run reproducing the bug. The backtrace log is empty with first try on 0.16.1 but on 0.16.2 with trying to get it to work did I get a "No playback devices" error with trying "RestartIntegratedClient" and "RefreshPlayback" once or a few times. That produced a proper backtrace log: ``` Got a panic: PanicInfo { payload: Any { .. }, message: Some( called `Result::unwrap()` on an `Err` value: StreamError(DefaultStreamConfigError(DeviceNotAvailable)), ), location: Location { file: "/home/nathan/.cargo/registry/src/index.crates.io-1cd66030c949c28d/librespot-playback-0.4.2/src/audio_backend/rodio.rs", line: 178, col: 53, }, can_unwind: true, force_no_backtrace: false, } Stack backtrace: 0: backtrace::capture::Backtrace::new 1: spotify_player::init_logging::{{closure}} 2: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/alloc/src/boxed.rs:2021:9 std::panicking::rust_panic_with_hook at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:735:13 3: std::panicking::begin_panic_handler::{{closure}} at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:609:13 4: std::sys_common::backtrace::__rust_end_short_backtrace at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/sys_common/backtrace.rs:170:18 5: rust_begin_unwind at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:597:5 6: core::panicking::panic_fmt at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/panicking.rs:72:14 7: core::result::unwrap_failed at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/result.rs:1652:5 8: librespot_playback::audio_backend::rodio::mk_rodio 9: std::sys_common::backtrace::__rust_begin_short_backtrace 10: core::ops::function::FnOnce::call_once{{vtable.shim}} 11: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/alloc/src/boxed.rs:2007:9 <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/alloc/src/boxed.rs:2007:9 std::sys::unix::thread::Thread::new::thread_start at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/sys/unix/thread.rs:108:17 ``` **Environment** - OS: Ubuntu Noble 24.04 LTS (Development Branch) - Application version: 0.16.1 for when 'alsa-backend' was tested and 'rodio-backend' for both 0.16.2 and 0.16.1 (so it appears that there that this issue is still present on 0.16.2) - Application features: if applicable, provide [cargo features](https://doc.rust-lang.org/cargo/reference/features.html) used to build `spotify_player` Default settings apart from the one instance from when the backend being changed to 'alsa-backend' in which the application was built with '--no-default-features --features alsa-backend' **Additional context** It's highly unlikely that this is something that relates to my device's architecture, but the device Spotify_Player is being used on is an ARMv7h device. I also used Clang as the compiler.

kerem

2026-03-14 13:28:09 +03:00

closed this issue
added the
help wanted

bug
labels

kerem commented

2026-03-14 13:28:26 +03:00

Author

Owner

@aome510 commented on GitHub (Dec 20, 2023):

This is the first time I have seen this kind of error. A brief search leads me to https://github.com/RustAudio/rodio/issues/267. Can you try to install pulseaudio-alsa to see if it fixes the issue?

@aome510 commented on GitHub (Dec 20, 2023): This is the first time I have seen this kind of error. A brief search leads me to https://github.com/RustAudio/rodio/issues/267. Can you try to install `pulseaudio-alsa` to see if it fixes the issue?

kerem commented

2026-03-14 13:28:31 +03:00

Author

Owner

@nathan-2006 commented on GitHub (Dec 20, 2023):

Whoops! I should've mentioned that semi-recently did Ubuntu drop PulseAudio in favor of PipeWire. My system has both pipewire-alsa and pipewire-pulse

Is this project not compatible with PipeWire sound systems?

If I had to guess, it looks like it could work somehow: Issue #299

@nathan-2006 commented on GitHub (Dec 20, 2023): Whoops! I should've mentioned that semi-recently did Ubuntu drop PulseAudio in favor of PipeWire. My system has both `pipewire-alsa` and `pipewire-pulse` Is this project not compatible with PipeWire sound systems? If I had to guess, it looks like it could work somehow: [Issue #299](https://github.com/aome510/spotify-player/issues/299l)

kerem commented

2026-03-14 13:28:36 +03:00

Author

Owner

@Tranquill6 commented on GitHub (Apr 16, 2024):

I don't mean to bring up an old issue, but I am having the same problem as @nathan-2006 and haven't had any luck to solve it. I am just relying on ALSA/Pipewire for audio but I get the same error whenever I try to select my arch linux as a device. DId you end up figuring out how to fix it?

@aome510 I know you brought up to install pulseaudio-alsa but I am using pipewire (with pipewire-pulse installed). I am using Arch Linux 6.8.2

@Tranquill6 commented on GitHub (Apr 16, 2024): I don't mean to bring up an old issue, but I am having the same problem as @nathan-2006 and haven't had any luck to solve it. I am just relying on ALSA/Pipewire for audio but I get the same error whenever I try to select my arch linux as a device. DId you end up figuring out how to fix it? @aome510 I know you brought up to install `pulseaudio-alsa` but I am using pipewire (with pipewire-pulse installed). I am using Arch Linux 6.8.2

kerem commented

2026-03-14 13:28:41 +03:00

Author

Owner

@aome510 commented on GitHub (Apr 16, 2024):

I think it should work with pipewire. I no longer have access to Linux machine so couldn't test it myself. Did you get the same DeviceNotAvailable error? You can also try other audio backends to find one that works.

@aome510 commented on GitHub (Apr 16, 2024): I think it should work with `pipewire`. I no longer have access to Linux machine so couldn't test it myself. Did you get the same `DeviceNotAvailable` error? You can also try [other audio backends](https://github.com/aome510/spotify-player?tab=readme-ov-file#audio-backend) to find one that works.

kerem commented

2026-03-14 13:28:46 +03:00

Author

Owner

@Tranquill6 commented on GitHub (Apr 16, 2024):

I think it should work with pipewire. I no longer have access to Linux machine so couldn't test it myself. Did you get the same DeviceNotAvailable error? You can also try other audio backends to find one that works.

Yep, I got the same error. I tried the alsa-backend but everytime I tried to play a song it seemed to have crashed to the terminal I am using but not completely. It was weird, it like glitched weird and I had to force close it. It didn't post anything to the .log file or .backtrace file so not sure what was going on there

@Tranquill6 commented on GitHub (Apr 16, 2024): > I think it should work with `pipewire`. I no longer have access to Linux machine so couldn't test it myself. Did you get the same `DeviceNotAvailable` error? You can also try [other audio backends](https://github.com/aome510/spotify-player?tab=readme-ov-file#audio-backend) to find one that works. Yep, I got the same error. I tried the alsa-backend but everytime I tried to play a song it seemed to have crashed to the terminal I am using but not completely. It was weird, it like glitched weird and I had to force close it. It didn't post anything to the .log file or .backtrace file so not sure what was going on there

kerem commented

2026-03-14 13:28:51 +03:00

Author

Owner

@aome510 commented on GitHub (Apr 16, 2024):

Does any of rodio examples work for you? For example, cargo run --example music_mp3. I cannot reproduce this issue on my end, so nothing much I can help unfortunately

@aome510 commented on GitHub (Apr 16, 2024): Does any of [rodio examples](https://github.com/RustAudio/rodio/tree/master/examples) work for you? For example, `cargo run --example music_mp3`. I cannot reproduce this issue on my end, so nothing much I can help unfortunately

kerem commented

2026-03-14 13:28:56 +03:00

Author

Owner

@Tranquill6 commented on GitHub (Apr 17, 2024):

@aome510 I will try other backends and post back here on how that goes. What determines which audio device is used? When I use a command like aplay -l I have two cards, my main one is first but I know on spotify-tui, I had to specify for that to get used. Is there anything like that for spotify-player?

@Tranquill6 commented on GitHub (Apr 17, 2024): @aome510 I will try other backends and post back here on how that goes. What determines which audio device is used? When I use a command like `aplay -l` I have two cards, my main one is first but I know on spotify-tui, I had to specify for that to get used. Is there anything like that for spotify-player?

kerem commented

2026-03-14 13:29:01 +03:00

Author

Owner

@Tranquill6 commented on GitHub (Apr 17, 2024):

@aome510 I fixed my issue, I needed to use the pulseaudio backend, then I went into my pavucontrol (volume control) and made sure my audio device was set to primary, and unmuted then everything worked really well!

Note to others, make sure to have pipewire-pulse installed if you are using pipewire since there isn't a direct backend for it

@Tranquill6 commented on GitHub (Apr 17, 2024): @aome510 I fixed my issue, I needed to use the pulseaudio backend, then I went into my pavucontrol (volume control) and made sure my audio device was set to primary, and unmuted then everything worked really well! Note to others, make sure to have `pipewire-pulse` installed if you are using pipewire since there isn't a direct backend for it

kerem commented

2026-03-14 13:29:06 +03:00

Author

Owner

@aome510 commented on GitHub (Apr 17, 2024):

Nice. Glad that you fixed it yourself.

but I know on spotify-tui, I had to specify for that to get used. Is there anything like that for spotify-player?

I'm pretty sure spotify-tui doesn't support specifying audio device as they don't support streaming. I think you may mean Spotify device which spotify_player also supports, but you need to set up Spotify Connect before. Refer to https://github.com/aome510/spotify-player?tab=readme-ov-file#spotify-connect for more details

@aome510 commented on GitHub (Apr 17, 2024): Nice. Glad that you fixed it yourself. > but I know on spotify-tui, I had to specify for that to get used. Is there anything like that for spotify-player? I'm pretty sure `spotify-tui` doesn't support specifying audio device as they don't support streaming. I think you may mean **Spotify device** which `spotify_player` also supports, but you need to set up Spotify Connect before. Refer to https://github.com/aome510/spotify-player?tab=readme-ov-file#spotify-connect for more details

kerem commented

2026-03-14 13:29:11 +03:00

Author

Owner

@Tranquill6 commented on GitHub (Apr 17, 2024):

@aome510 Ah, you're right, I am thinking of the device config option for spotifyd. I am so thankful that spotify-player doesn't rely on something like spotifyd

@Tranquill6 commented on GitHub (Apr 17, 2024): @aome510 Ah, you're right, I am thinking of the `device` config option for spotifyd. I am so thankful that spotify-player doesn't rely on something like spotifyd

Rows
Columns

[GH-ISSUE #320] Music Continues to Go Through The Speakers Despite Despite The Presence of Bluetooth Headphones #1104