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

Volume control doesn't catch processes from different inputs #159

Open
Jeremy2131 opened this issue Feb 7, 2024 · 3 comments · May be fixed by #162
Open

Volume control doesn't catch processes from different inputs #159

Jeremy2131 opened this issue Feb 7, 2024 · 3 comments · May be fixed by #162

Comments

@Jeremy2131
Copy link

Hello, so I bought a new headset and the problem is I can route different apps through different inputs (Game/Media/Chat) but Volume control catches processes only from the Game input because Game is the default one
Can it be counted as a bug or a feature to be introduced?

@Dregu
Copy link

Dregu commented Feb 22, 2024

Yep seems like if you use the "App volume and device preferences" in W10 to set a non-default output for an app, VolumeControl will just adjust sessions in the default device for everything anyway. Except if you launch the other app first and then restart VolumeControl it will properly find the session on the other device and can even jump between sessions on different output devices, so clearly there's support for this, it's just bugged.

Edit: After snooping around it looks more like there isn't support for multiple sessions on the same process and the workaround just work by accident for me, because the non-default device is initialized first on launch by chance. After the other app is reopened, the sessions are created in a different order and this time VC picks the silent one.

Only some apps are broken for me (firefox and ffplay) because they are creating sessions on both devices (default + user defined) but only playing sound on the second one. This might be a quirk of how W10 does things with these non-default outputs. Then again spotify works just fine with VC when routed to the alternative device exactly the same way 🤷🏻.

A good fix might be to adjust volume on all open sessions for the process, or just the ones making sounds recently...

@Dregu
Copy link

Dregu commented Feb 22, 2024

Looks like changing AddSession() to compare the actual SessionIdentifier for duplicates instead of only PIDs does add multiple-devices-per-process support and fixes my main issue, but needs some more work to filter out the sessions in disabled state in the notification/hotkey iteration. Or maybe only hide the disabled sessions from processes that also have active sessions. I don't see any reason to quickly adjust the volume of any app/session that isn't currently producing sound though.

I might make a PR for some of these things later...

@Dregu Dregu linked a pull request Feb 22, 2024 that will close this issue
@teadrinker2015
Copy link

I'm not quite understand the circumstance you're describing. I'll elaborate mine anyway, to facilitate the replication of this issue hopefully.

  • Foobar2000's output set to a speaker, Firefox output to the default device. At the beginning, default device is also that speaker.
  • Then, I connect to a bluetooth headphone. consequently, it become the default now, and Firefox is redirect to the headphone, perfectly. Then I adjust volume.
  • Everything is broken.

Sorry, I'm not intend to make a joke, but I can't remember the exact problem I had encountered. I recently replaced my bluetooth adapter to an audio-only bluetooth adapter, which act as an always-on audio output device, ignorant of which and whether my haedphone is connected. I just realized this change solved my problem.
That's just the last piece of my whole workaround solutions package. Maybe I just want to share this to people.

If you're using a generic normal bluetooth adapter, buy another one. (as previously described)

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

Successfully merging a pull request may close this issue.

3 participants