Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to specify audio playback device #444

Open
aurismat opened this issue May 3, 2024 · 2 comments
Open

Add option to specify audio playback device #444

aurismat opened this issue May 3, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@aurismat
Copy link

aurismat commented May 3, 2024

Is your feature already implemented in the latest master?
Not that I am aware of; please correct me if that's the case.

Is your feature request related to a problem? Please describe.
I've been using spotify-player for a couple weeks now and it has been excellent for daily use, except for one issue that I have run into on my Windows system - I cannot specify the playback device to output to my virtual audio cables(which I use for leveling audio for specific app groups: music, games, other programs etc).

librespot, which from what I understand spotify-player depends on as a library, has this option built-in (-d flag), and I think it'd be useful to implement something to that extent to spotify-player.

I have attempted to specify the audio device in the config file via device = "Playback device's name", but it had no effect(from what I glanced over the source, only seems to parse options listed in docs/config.md#device-configurations?)

Describe the solution you'd like
I'd like to see one of these implementations added:

  • CLI option to specify the output device(similar to librespot, a -d flag) to override the playback device from the OS default;
  • Config option in the [device] block to specify the playback device, e.g. device = "Different playback audio device";
  • (Windows-specific) Allow Windows specified output(via "App volume and device preferences" menu) to specify which playback device should be used.

Describe alternatives you've considered
My current botched solution to this is to launch librespot in the background with my specified audio device and then point spotify-player's config to that, and kill librespot when I'm done with spotify_player but IMO that is not exactly an elegant solution when spotify-player already has librespot as a library, hence me creating this FR. Below is the script that I use to do this, it is a Powershell script(and a very crude one), but it does the job for my use case.

librespot -n "librespot" -F computer --device "Virtual audio cable device" -q -u <redacted> -p <redacted> &
$job_id = Get-Job | Where-Object { $_.Command -match "librespot" } | Select-Object -ExpandProperty Id
spotify_player
Remove-Job $job_id -Force

Additional context
I am not familiar with Rust myself, and I am aware that Windows support is probably low-priority, but I hope this FR will be considered. Thank you for your great work on this project!

@aurismat aurismat added the enhancement New feature or request label May 3, 2024
@LegionDzn
Copy link

LegionDzn commented May 4, 2024

This can be done on windows. See: https://winaero.com/audio-output-device-apps-individually-windows-10/

@aurismat
Copy link
Author

aurismat commented May 4, 2024

Normally, under Windows it can be done and I'm well aware of it; except it doesn't do anything at all in the case of spotify-player, and I have verified this with OBS by capturing that specific virtual audio cable's output between what spotify-player does on it's own vs what is supposed to happen by utilizing librespot and pointing it to that audio device.

Current behaviour, where spotify-player does not remap to the virtual cable
image

What it should be doing, portrayed by having a librespot open and pointed to VB-Audio's Cable C Input. Note that Windows 10's audio device preferences has no effect over this.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants