Music Continues to Go Through The Speakers Despite Despite The Presence of Bluetooth Headphones

[nathan-2006]

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.

[aome510]

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?

[nathan-2006]

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

[Tranquill6]

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

[aome510]

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.

[Tranquill6]

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

[aome510]

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

[Tranquill6]

@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]

@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

[aome510]

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

[Tranquill6]

@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