WASAPI can't initialize audio client: CoInitialize has not been called.

[rom1v]

The call to SDL_OpenAudioDevice(NULL, 0, &desired, &obtained, 0) fails with the following error:

WASAPI can't initialize audio client: CoInitialize has not been called.

Maybe related: #5552 (but apparently it still fails in 2.26.3)

(source: Genymobile/scrcpy#3825)

[icculus]

Oh weird, let me see if I can reproduce it here.

Is this opening the audio device without initializing the video subsystem? I'm wondering if we unintentionally relied on that to initialize COM.

[rom1v]

Is this opening the audio device without initializing the video subsystem?

No, the video subsystem is necessarily initialized. The audio subsystem is initialized unless audio is explicitly disabled (in other words, it is initialized in this case).

[icculus]

...are you opening an audio device from a background thread? It certainly seems like we are not calling WIN_CoInitialize() during device open, so that would likely trigger this issue.

[rom1v]

...are you opening an audio device from a background thread?

Yes.

Concretely, I receive an audio stream from a socket from a demuxer thread. Once the stream starts, it opens its sinks (a decoder), which itself opens its sinks (an audio player). This is from there that I call SDL_OpenAudioDevice(NULL, 0, &desired, &obtained, 0);.

It is called from there for several reasons:

• only from here we know the input format (sample rate, number of channels…) to initialize the SDL_AudioSpec
• this is the same thread which will receive the audio packets
• if the audio stream is disabled (because the device could not capture for example), there is no need to open the SDL device.

[slouken]

Yes, we should call WIN_CoInitialize() during device opening and cleanup during device closing. It's safe to call this on the same thread, so it should be fine.

[icculus]

Okay, just confirming. I'll add in a CoInitialize call, which should fix this.

[icculus]

#7489 is untested but should fix this for SDL2, but please close the audio device from the same thread you opened it, or it will cause a leak.

For SDL3, I'm reworking how audio devices get opened, so hopefully this will be a non-issue there in any case.

[rom1v]

#7489 is untested but should fix this for SDL2

Thank you very much 👍

Will the CI generate a ready-to-use SDL2.dll so that I can submit it to users that have reported this problem?

but please close the audio device from the same thread you opened it, or it will cause a leak.

Yes, opening and closing is from the same thread. 👌

[icculus]

Will the CI generate a ready-to-use SDL2.dll so that I can mail submit it to users that have reported this problem?

I don't believe it does at the moment. :(

[icculus]

2.26.5 should have this fix, if you want to grab those binaries.

[rom1v]

2.26.5 should have this fix

No, I think it will only be in 2.28.

[icculus]

Oh, you're right, sorry about that!

[icculus]

I'm closing this under the assumption it's fixed in 2.28.0, which is coming shortly. Let's reopen this if there's still an issue, though.

[rom1v]

@icculus I confirm that SDL 2.28RC1 seems to fix the probem: Genymobile/scrcpy#3825 (comment) 🎉

[icculus]

Thank you for patiently waiting for binaries for so long, and then jumping right in to test them!

[rom1v]

I don't know if this is related, but sometimes, there is an error:

WASAPI can't find requested audio endpoint: Element not found.

While with directsound it seems to work. See Genymobile/scrcpy#4111 (just for your information).

[slouken]

I don't know if this is related, but sometimes, there is an error:

WASAPI can't find requested audio endpoint: Element not found.

While with directsound it seems to work. See Genymobile/scrcpy#4111 (just for your information).

Please open a separate issue if you'd like this tracked, we usually don't look at closed bug reports.