[ALSOFT] (EE) Failed to initialize audio client:0x8007001f ?

[xuandu]

In win10, win32-exe; the computer have three device: stereo mix(input),headset，and Line-in（phone +3.5mm）; when I set the stereo mix to do the default device,other is ready status, my EXE recording with the microphone(headset),will have this error,and I can not open the mic device;

use the 1.20 openal or 1.17 have the same result;

but when I run the exe at win7 computer, have no error;

[kcat]

That doesn't seem to be a valid error code listed for IAudioClient::Initialize, which that message's error code is from. Actually, I'm not seeing that error code defined anywhere, at least in Wine's headers. Are you able to get a full trace log?

[MikuAuahDark]

0x8007001F (Win32 error 0x1F because 8007 is Win32 error codes) is ERROR_GEN_FAILURE. Quick impression sounds like hardware problem?

[rewrking]

Bumping this because I hit this error in this specific scenario:

• The only active display device is an HDTV via HDMI (LG C1 in this case)
• The default audio device is the HDMI audio
• The audio device is in use by another application - in my case, Media Player Classic MPC-HC 2.0.0.122 (485943282)

When I launch my own app (with MPC going - can be paused), an exception is thrown from alcCreateContext

[ALSOFT] (EE) Failed to initialize audio client: 0x8889000a
[ALSOFT] (EE) Device error: 0x8889000a
[ALSOFT] (WW) Error generated on device 0000026092F83C50, code 0xa001

I'm using OpenAL 1.23.1

[kcat]

That error seems to correspond to AUDCLNT_E_DEVICE_IN_USE, suggesting the other app has the device open in exclusive mode which will prevent other apps from using the device.

[rewrking]

Thanks. I'm just working around it for now by disabling audio. The other idea I had was polling until the device becomes available (if at all), and deferring source/buffer generation until then. Is there another best practice to handle this sort of the thing?

Can audio devices have exclusivity on macos and linux as well, or are those always considered shared?

[kcat]

It is possible on Linux (I don't know if PipeWire or PulseAudio have the option for exclusive device access like WASAPI does, but it is possible for an app to open the hardware device directly through ALSA which will prevent anything else from using the device while it's in use), although it's very rare and abnormal to happen. I don't know about macOS.

I don't know if there's a general best practice, but the typical thing I've seem done is to report the problem and:

• Stay with no sound, having an option somewhere for the user to retry once the offending app stops, or
• Stay with no sound, periodically trying to reinitialize it automatically, or
• Try another device, if one is available

You can also try a mix of these, for example try once before failing, then popping up a message with an option to keep trying periodically for a bit of time, an option to select another device, or an option to continue with no sound until the user wants to explicitly retry.