-
Notifications
You must be signed in to change notification settings - Fork 456
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 = "*" | ||
|
Member
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.
Author
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
Author
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
Member
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
Member
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).
Author
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
Member
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. 😢 that's a real pity. There's been an express request from the community to support multiple
Author
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. The only solution I can think of is an incredibly ugly one: publish multiple crates (containing just the relevant code) for each supported Anything that depends on the We could consider avoiding the side-dependency issue by rewriting all Windows-related code to only depend on
Member
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. Ouch 😓 Anyway the path forward seems to be anticipating v0.61+ right?
Author
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. Sorry for the late reply. With the current setup, we'd have to pick a I can't think of anything we could do with We could noodle around with a Honestly, I think the pragmatic choice would be a policy of following the latest |
||
| 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!