search

libsdl-org / SDL

Simple Directmedia Layer
https://libsdl.org
zlib License
9.92k stars 1.84k forks source link

audio issue with wasapi and Intel Display Audio devices #5571

Closed sezero closed 1 year ago

sezero commented 2 years ago

This was reported to me by @j4reporting for quakespasm at https://github.com/sezero/quakespasm/issues/23 - any insights?

Quoting as is:

Audio is not initialized on WIndows if 'Intel display audio' is the only available audio device AND a modeset is issued. This is a known issue with Intel Drivers (see Intel document ). 

Sound Initlalisation
Coundn't opem SDL audio:  WASAPI can't find requested audio endpoint: Element not found.

I could fix this by simply retrying again 2 seconds later.

Unfortunately audio device is also lost later in the game when switching to another video resolution or switching from vid_fullscreen 0 <-> 1. What is needed is some kind of snd_restart command and ideally a check if the audio device is available and if not, an automatic restart of the audio device.

the same issue can be observed with vkQuake, Ironwail and probably with other forks.

Why had that worked for me all this years? I had a headphone connected to the system (realtek HD audio) and Quakespasm would find the headphone, initialize audio and when Intel Display Audio re-apperared, SDL/ WASAPI would switch back to the default audio device!

icculus commented 2 years ago

This is wild! So for up to 8 seconds after changing the display resolution, the audio device goes missing...? Wow.

This feels like something we should look for by vendor id and add some special case code for.

sezero commented 2 years ago

If I'm reading the linked docs correctly, Intel says they are innocent and blame apps. Never heard this kind of an issue though, until today - so I'm not 100% sure about who to blame - quakespasm or intel drivers or SDL.

eloj commented 2 years ago

The suggestion that you should retry for more than 8 seconds after a modeset just seems baffling. How is that an OK user experience? "The spec allows it and gosh darned it we're going to use every second!" -- Intel

icculus commented 2 years ago

Yeah, this is 100% Intel's fault but we can probably handle this as a special case. I'll look into it.

j4reporting commented 2 years ago

The 'good' news is that I cannot reproduce this strange behaviour on an 11th Gen Core system ( Xe iGPU). The audio device now has the name 'HD Audio Driver for Display Audio' instead of 'Intel Display Audio' on previous Core generations. The architecture of the new driver looks similar to the NVidia driver. I suspect that Intel's 6th to 10th Gen Core CPUs are affected.

The OpenAL-soft library has some extensions that allow to recover a temporarily disconnected or unavailable audio device.

How is that an OK user experience?

normally this is not a big problem. On my old Skylake system (NUC 6I5SYH) and a QHD display, the audio device is available 1-2 seconds after the monitor exits the modeset. It is quite possible that Intel also includes the duration that the monitor needs for the modeset.

icculus commented 1 year ago

I'm just noting, having messed around with HDMI audio more recently, that it's extremely common for it to take a few seconds to get audio going when switching to such an audio device; I've seen this on Windows, Linux and macOS...the difference is that the OS level device doesn't vanish or fail, it just doesn't make any sound until it's ready, and I think that's the crux of the issue here.

For now, I'm going to pass on trying to workaround this in SDL, as it seems to be an older hardware issue, and we're continuing to push towards people using fullscreen_desktop instead of changing the resolution, which should avoid this bug.

I'm not closing this as WONTFIX yet, in case it's more widespread than I assume, but I'm bumping from the milestone.

j4reporting commented 1 year ago

I think this can be split in two issues

  1. the initial SDL_OpenAudio call when the Intel audio device is not yet available shortly after the modeset usually I can fix this in source with 2nd try after a short delay of 1-2 seconds

  2. losing an already aquired audio device after another modeset later on (e.g. changing program's video resolution ) for some reason only wasapi is affected. SDL_AUDIODRIVER=directsound works can this be related to https://github.com/libsdl-org/SDL/issues/7044 ?

I have not tested this myself, but I guess a driver like Virtual Audio Cable https://vb-audio.com/Cable/ may be a good workaround for affected systems. Virtual Audio Cable will be the system's default audio device, always available, and the output can be forwarded to the Intel Audio device.

icculus commented 1 year ago

(Following up from #7044, we should be good here, too, but please let me know if this issue still persists!)