-
Notifications
You must be signed in to change notification settings - Fork 442
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 all 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,21 @@ 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. When enabled: | ||
# - Audio automatically reroutes when the default device changes | ||
# - Streams survive device changes (e.g., plugging in headphones) | ||
# - Requires Windows 8 or later | ||
# | ||
# Disable this feature if supporting Windows 7 or earlier. | ||
wasapi-virtual-default-devices = [] | ||
|
||
# Deprecated, the `oboe` backend has been removed | ||
oboe-shared-stdcxx = [] | ||
|
||
|
@@ -31,7 +41,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 +59,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 |
||
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-autorouting
or something? (I'm usingwasapi
because it looks likecpal
supports ASIO as well, but I'm happy to change towindows
if that sounds better)