-
Notifications
You must be signed in to change notification settings - Fork 445
WASAPI: Use ActivateAudioInterfaceAsync with virtual device IDs for default devices
#1027
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
base: master
Are you sure you want to change the base?
Changes from 13 commits
d68c885
dd00d9e
b8892b9
7e82d99
8215207
66ed6be
f208797
c7395ce
5722483
6a17582
04c8eaa
0830b3f
87d5df3
9377948
f65a156
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,11 +10,20 @@ edition = "2021" | |
| rust-version = "1.70" | ||
|
|
||
| [features] | ||
| default = ["wasapi-virtual-default-devices"] | ||
|
|
||
| asio = [ | ||
| "asio-sys", | ||
| "num-traits", | ||
| ] # Only available on Windows. See README for setup instructions. | ||
|
|
||
| # Enable virtual default devices for WASAPI, so that audio will be | ||
| # automatically rerouted when the default input or output device is changed. | ||
| # | ||
| # Note that this only works on Windows 8 and above. It is turned on by default, | ||
| # but consider turning it off if you are supporting an older version of Windows. | ||
| wasapi-virtual-default-devices = [] | ||
|
|
||
| # Deprecated, the `oboe` backend has been removed | ||
| oboe-shared-stdcxx = [] | ||
|
|
||
|
|
@@ -31,7 +40,12 @@ clap = { version = "4.5", features = ["derive"] } | |
| # versions when bumping to a new release, and only increase the minimum when absolutely necessary. | ||
| # When updating this, also update the "windows-version" matrix in the CI workflow. | ||
| [target.'cfg(target_os = "windows")'.dependencies] | ||
| windows = { version = ">=0.58, <=0.62", features = [ | ||
| # The `implement` feature was removed in windows-0.61, which means that we can't | ||
| # use older versions of the `windows` crate without explicitly activating `implement` | ||
| # for them, which will cause problems for >=0.61. | ||
| # | ||
| # See <https://github.com/microsoft/windows-rs/pull/3333>. | ||
| windows = { version = ">=0.61, <=0.62", features = [ | ||
| "Win32_Media_Audio", | ||
| "Win32_Foundation", | ||
| "Win32_Devices_Properties", | ||
|
|
@@ -44,6 +58,8 @@ windows = { version = ">=0.58, <=0.62", features = [ | |
| "Win32_Media_Multimedia", | ||
| "Win32_UI_Shell_PropertiesSystem", | ||
| ] } | ||
| # Explicitly depend on windows-core for use with the `windows::core::implement` macro. | ||
| windows-core = "*" | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm... yes, that is a problem. I'll see what I can do; the problem I saw was that the CI would fail to resolve There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, this is a problem. I can see three options here:
I'll ask around regarding 3, and ask in that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for asking in The frequent API breakage of these There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah especially with how Microsoft is treating their users on windows 11 we will want to support windows 10 as long as we can. Thank you soo much for your work in that regard philpax and roderick. I know its a pain to support te windows platform, but the impact is so high. Especially for gamedev (bevy). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm pretty sure newer versions of the Speaking of, I was thinking of another solution: catpuccin-egui uses individual features for each supported version of We could do something similar for both Of course, this comes with the downside that the user needs to opt into an older version of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, wait, just realised that wouldn't work... the |
||
| audio_thread_priority = { version = "0.34.0", optional = true } | ||
| asio-sys = { version = "0.2", path = "asio-sys", optional = true } | ||
| num-traits = { version = "0.2.6", optional = true } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, a documentation suggestion:
Second, I wonder if we should invert the feature and rename it to
windows-legacy(disabled by default). I'm not so sure if "virtual default devices" clearly communicates its intention. What do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good shout on the docs, will do first.
I think inverting the feature would be more ergonomic, but the Cargo docs suggest that features should always be additive:
I think it's probably fine - I don't see a way for this to cause a conflict with another package, as you'd want this to be controlled at the application level anyway - but I'm not sure. For now, I'll just action the doc change, but I'm open to the inversion if you think it's compatible with the norms of the ecosystem.
Feature name: Hmm, yeah, I'm not sold on it either; it was what first came to mind to cover the concept of activating the output with a virtual default device, but it's not the most self-descriptive thing. Maybe
wasapi-default-device-autoroutingor something? (I'm usingwasapibecause it looks likecpalsupports ASIO as well, but I'm happy to change towindowsif that sounds better)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can still argue it's additive: it enables legacy support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, will action!