search

aome510 / spotify-player

A Spotify player in the terminal with full feature parity
MIT License
3.13k stars 137 forks source link

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

Open nathan-2006 opened 7 months ago

nathan-2006 commented 7 months ago

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

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 commented 7 months ago

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 commented 7 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

@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