WASAPI: Address COM initialization issues

[kinetiknz]

As part of debugging a crash occurring with exclusive mode WASAPI streams (PR #415), it was discovered that the cause was libcubeb's inconsistent approach to COM initialization.

The current code uses auto_com to initialize COM on the stack (with RAII handling uninitialization) in each libcubeb API call. In the case of the exclusive mode crash, it turned out that the IAudioClient held an reference to the COM apartment, which was destroyed at the end of wasapi_stream_init by the auto_com destructor, resulting in a UAF crash.

Shared mode streams don't seem to trigger this particular issue, and it's likely that libcubeb's approach to COM initialization is rescued by the fact that calling threads (e.g. within Gecko) have already initialized COM at some other level and result in auto_com simply bumping a refcount and never actually triggering (un)initialization.

It seems like the best approach may be to remove COM initialization from libcubeb and simply document that the caller must initialize COM in MTA mode in any threads that expect to call in to libcubeb. That would avoid the apartment lifetime issue revealed by the exclusive mode PR.

[djg]

It seems like the best approach may be to remove COM initialization from libcubeb and simply document that the caller must initialize COM in MTA

That sounds like the best approach to me.

[kinetiknz]

Fixed by #424.