"fatal error: hr != CO_E_NOTINITIALIZED" when running all examples on Windows

[nyanpasu64]

I tried running cargo build --examples and running the resulting examples. It didn't work well.

C:\Users\username\src\cubeb-rs\cubeb-sys\libcubeb\src\cubeb_wasapi.cpp:1500 - fatal error: hr != CO_E_NOTINITIALIZED

(I do not get a Rust backtrace.)

wasapi_init() has the comment:

  /* We don't use the device yet, but need to make sure we can initialize one
     so that this backend is not incorrectly enabled on platforms that don't
     support WASAPI. */

Which makes no sense considering that https://github.com/kinetiknz/cubeb/blob/8c3e32bd24933f82220b66c88c845c4b2bdf28e7/src/cubeb_wasapi.cpp is a huge file, and not an empty stub. Is this Cubeb comment outdated, and should I file a Cubeb issue?

Changing wasapi_init() to return CUBEB_ERROR; causes cubeb-rs examples to build, and devices.exe to report nothing but WinMM, instead of crashing in a C++ assertion.

---

https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex it appears that CoInitialize[Ex] was not called in the "current" thread, and https://github.com/kinetiknz/cubeb/issues/534 is an upstream issue discussing the COM initialization. Currently it must be done by the app, not by cubeb itself. Dolphin emulator calls CoInitialize(nullptr) for raw WASAPI., but doesn't do it for Cubeb without running into this issue (maybe they use older Cubeb).

rustc 1.37.0 stable-x86_64-pc-windows-msvc Windows 10 x64, Realtek sound card with Microsoft (not Dell/Realtek) drivers, which expose speakers and headphones as separate devices.

[kinetiknz]

libcubeb used to (try to) manage COM initialization internally, but it ran into various problems including those discussed in https://github.com/kinetiknz/cubeb/issues/416. The solution was to move responsibility for COM initialization to the library user and document the requirement: https://github.com/kinetiknz/cubeb/blob/8c3e32bd24933f82220b66c88c845c4b2bdf28e7/include/cubeb/cubeb.h#L423

So this is a bug in the cubeb-rs tests, where it hasn't been updated to initialize COM first. But as you found, https://github.com/kinetiknz/cubeb/issues/534 is now discussing alternative approaches to managing COM inside libcubeb.

[nyanpasu64]

it seems that cubeb documents their code using doxygen comments. But their readme is nearly empty, and they don't seem to build and publish doxygen online. Where can i find docs online without installing doxygen myself?

And do I need Windows-only COM initialization code?

[kinetiknz]

it seems that cubeb documents their code using doxygen comments. But their readme is nearly empty, and they don't seem to build and publish doxygen online. Where can i find docs online without installing doxygen myself?

They're not online anywhere AFAIK. It might be worth filing an issue against the cubeb repository to address that.

And do I need Windows-only COM initialization code?

Yes, for now you need to CoInitialize{,Ex} on each thread you call into libcubeb from. That requirement may disappear again when https://github.com/kinetiknz/cubeb/issues/534 is resolved.

[kinetiknz]

https://github.com/kinetiknz/cubeb/pull/542 will address this inside cubeb.