starred/spotify-player

Fork 0

mirror of https://github.com/aome510/spotify-player.git synced 2026-04-26 09:25:49 +03:00

[GH-ISSUE #672] Audio playback does not route to output correctly on Windows (Windows Terminal) #1329

New issue

Open

opened 2026-03-14 14:26:09 +03:00 by kerem · 5 comments

kerem commented

2026-03-14 14:26:09 +03:00

Owner

Originally created by @selvmaya on GitHub (Jan 30, 2025).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/672

Describe the bug
The audio output of spotify-player does not respect the audio routing chosen in Windows 10 (& 11?) per-app audio settings.
It seems to always use the default output no matter what.

To Reproduce
Open Windows terminal, run spotify-player. Either select the per-app setting in Windows "App volume and device preferences" (Win10) before or during/between playback (refreshing does not help).

Expected behaviour
The audio routes to the correct audio output (see C in reference image) instead of default output (see A in reference image).
This works for (nearly) every single windows application. Exceptions to this usually only have problems routing while the application is running, but usually still works if you select the app route before it starts. Specific apps fix it if you refresh the setting during runtime.

Log and backtrace
spotify-player-25-01-30-16-33.log
GitHub did not let me upload a (0KB) backtrace file (also seems irrelevant).

Screenshots
Reference image:

This image shows spotify_player in a Windows Terminal window, the Windows 10 "App volume and device preferences" settings window, as well as live audio software Voicemeeter.
Note: Firefox is not playing any audio here, only spotify-player is. The fact that apps with individual sliders often show up in the default output or not at all in Voicemeeter is a common unrelated issue.

Environment

OS: Windows 10 Home 22H2
Application version: 0.20.4
Application features: default features + image + fzf
Extra build notes: Built using cargo-install with --config "lto=true"

Additional context
This could be a Windows Terminal bug or a audio backend (default: rodio) feature that is simply unimplemented. My surface-level look over the existing open/closed issues did not find an issue with this target problem. If there is a workaround (e.g. alternative backend) or a problem inherent to Windows Terminal, I would like to know (and this could be documented as a limitation).

Originally created by @selvmaya on GitHub (Jan 30, 2025). Original GitHub issue: https://github.com/aome510/spotify-player/issues/672 **Describe the bug** The audio output of `spotify-player` does not respect the audio routing chosen in Windows 10 (& 11?) per-app audio settings. It seems to always use the default output no matter what. **To Reproduce** Open Windows terminal, run `spotify-player`. Either select the per-app setting in Windows "App volume and device preferences" (Win10) before *or* during/between playback (refreshing does not help). **Expected behaviour** The audio routes to the correct audio output (see `C` in reference image) instead of default output (see `A` in reference image). This works for (nearly) every single windows application. Exceptions to this usually only have problems routing *while* the application is running, but usually still works if you select the app route before it starts. Specific apps fix it if you refresh the setting during runtime. **Log and backtrace** [spotify-player-25-01-30-16-33.log](https://github.com/user-attachments/files/18605304/spotify-player-25-01-30-16-33.log) GitHub did not let me upload a (0KB) backtrace file (also seems irrelevant). **Screenshots** Reference image: ![Image](https://github.com/user-attachments/assets/c1730309-6efe-4e82-8070-fed195807988) This image shows `spotify_player` in a Windows Terminal window, the Windows 10 "App volume and device preferences" settings window, as well as live audio software [Voicemeeter](https://vb-audio.com/Voicemeeter/). Note: Firefox is not playing any audio here, only `spotify-player` is. The fact that apps with individual sliders often show up in the default output or not at all in Voicemeeter is a common unrelated issue. **Environment** - OS: Windows 10 Home 22H2 - Application version: 0.20.4 - Application features: default features + `image` + `fzf` - Extra build notes: Built using `cargo-install` with `--config "lto=true"` **Additional context** This could be a Windows Terminal bug or a audio backend (default: `rodio`) feature that is simply unimplemented. My surface-level look over the existing open/closed issues did not find an issue with this target problem. If there is a workaround (e.g. alternative backend) or a problem inherent to Windows Terminal, I would like to know (and this could be documented as a limitation).

kerem added the

bug

label

2026-03-14 14:26:09 +03:00

kerem commented

2026-03-14 14:26:25 +03:00

Author

Owner

@selvmaya commented on GitHub (Jan 30, 2025):

I am not at all an expert in audio backends or how terminals handle audio, so I hope you'll bear with me if this is a dumb/naive report.

@selvmaya commented on GitHub (Jan 30, 2025): I am not at all an expert in audio backends or how terminals handle audio, so I hope you'll bear with me if this is a dumb/naive report.

kerem commented

2026-03-14 14:26:31 +03:00

Author

Owner

@aome510 commented on GitHub (Feb 4, 2025):

It seems to always use the default output no matter what.

I think this is expected. Sound is handled by https://github.com/RustAudio/rodio if you use the default audio backend. IIUC, the default behaviour is playing sound from whatever the default device the system is using and I don't know if there is a way to configure this. Maybe you can poke around with different audio backends as listed in https://github.com/aome510/spotify-player?tab=readme-ov-file#audio-backend

@aome510 commented on GitHub (Feb 4, 2025): > It seems to always use the default output no matter what. I think this is expected. Sound is handled by https://github.com/RustAudio/rodio if you use the default audio backend. IIUC, the default behaviour is playing sound from whatever the default device the system is using and I don't know if there is a way to configure this. Maybe you can poke around with different audio backends as listed in https://github.com/aome510/spotify-player?tab=readme-ov-file#audio-backend

kerem commented

2026-03-14 14:26:36 +03:00

Author

Owner

@selvmaya commented on GitHub (Feb 4, 2025):

If I do play around with backends then I'll report back if I have any interesting results.

@selvmaya commented on GitHub (Feb 4, 2025): If I do play around with backends then I'll report back if I have any interesting results.

kerem commented

2026-03-14 14:26:41 +03:00

Author

Owner

@User-3090 commented on GitHub (May 14, 2025):

Would be amazing if it supported bit-perfect playback on Windows using WASAPI exclusive mode. This might attract a whole new class of users, as many audio enthusiasts have wanted Spotify to add this for years: https://community.spotify.com/t5/Live-Ideas/Desktop-Support-WASAPI-Output/idi-p/1138616

If you add this feature and post on hydrogenaudio.org and head-fi.org, you'll attract many new users. It's been a highly requested feature for a long time.

In its current state, it's unusable for me, as I route desktop audio (default) and music through different virtual devices on my system.

@User-3090 commented on GitHub (May 14, 2025): Would be amazing if it supported bit-perfect playback on Windows using WASAPI exclusive mode. This might attract a whole new class of users, as many audio enthusiasts have wanted Spotify to add this for years: [https://community.spotify.com/t5/Live-Ideas/Desktop-Support-WASAPI-Output/idi-p/1138616](https://community.spotify.com/t5/Live-Ideas/Desktop-Support-WASAPI-Output/idi-p/1138616) If you add this feature and post on hydrogenaudio.org and head-fi.org, you'll attract many new users. It's been a highly requested feature for a long time. In its current state, it's unusable for me, as I route desktop audio (default) and music through different virtual devices on my system.

kerem commented

2026-03-14 14:26:46 +03:00

Author

Owner

@User-3090 commented on GitHub (May 16, 2025):

Seems PortAudio Backend actually supports WASAPI exclusive mode, but it needs to be enabled with paWinWasapiExclusive. Would it be possible add support for this configuration?

@User-3090 commented on GitHub (May 16, 2025): Seems PortAudio Backend actually supports WASAPI exclusive mode, but it needs to be enabled with paWinWasapiExclusive. Would it be possible add support for this configuration?