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.

Sign up for GitHub

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

Jump to bottom

Issue with IAudioClient::Initialize? #59

Closed
tomaka opened this issue Sep 1, 2015 · 0 comments · Fixed by #597
Closed

Issue with IAudioClient::Initialize? #59

tomaka opened this issue Sep 1, 2015 · 0 comments · Fixed by #597
Labels
bug

Comments

@tomaka
Copy link
Collaborator

tomaka commented Sep 1, 2015

On this page: https://msdn.microsoft.com/en-us/library/windows/desktop/dd370875%28v=vs.85%29.aspx

Note In Windows 8, the first use of IAudioClient to access the audio device should be on the STA thread. Calls from an MTA thread may result in undefined behavior.

cpal initializes COM in MTA mode.
@tomaka tomaka added the bug label Sep 1, 2015
@willstott101 willstott101 mentioned this issue Apr 23, 2019
Closed
@mitchmindtree mitchmindtree mentioned this issue Mar 16, 2020
Closed
@adumbidiot adumbidiot mentioned this issue Jul 17, 2021
Closed
ishitatsuyuki added a commit to ishitatsuyuki/cpal that referenced this issue Aug 8, 2021
@ishitatsuyuki
wasapi: Allow both threading models and switch the default to STA
03947af 
COM can prevent undefined behavior in either concurrency model by
performing marshaling when necessary. As a result, CoInitializeEx can be
called with either concurrency model, and in this case STA provides better
compatibility with other code requiring STA, e.g. ASIO backend or winit
drag-and-drop.

To dive into the detail, the entry point of WASAPI, MMDeviceEnumerator, is
registered with "both" threading model, which means that COM objects are
created with whatever the thread's concurrency model is set to. This raises
the concern that when STA is used, marshaling might make audio buffer
operations block on the main thread, breaking continuous audio processing.
However, the implementation actually uses free-threaded marshaller for
interfaces dealing with buffer operations, which effectively bypasses COM's
compatibility marshaling behavior and perform any API calls on the caller's
thread instead. Therefore, the interfaces would operate just fine on either
concurrency model.

For more details on COM's threading model, see [1].

[1] https://thrysoee.dk/InsideCOM+/ch04d.htm

Co-Authored-By: Henrik Rydgård <hrydgard@gmail.com>

Close RustAudio#59
Close RustAudio#348
Close RustAudio#504
Close RustAudio#530
Close RustAudio#538
Close RustAudio#572
@ishitatsuyuki ishitatsuyuki mentioned this issue Aug 8, 2021
Merged
@est31 est31 closed this as completed in #597 Aug 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

wasapi: Allow both threading models and switch the default to STA ishitatsuyuki/cpal
1 participant
@tomaka