Intel Display-Audio sucks (was: no audio with sdl >2.0.7) #209
Comments
|
First of all: Thanks a lot for testing and reporting the bug and for taking the time to try different SDL versions! :-) Ok, this is weird, especially considering that dhewm3 doesn't even use SDL for audio (but OpenAL).. I'll look at the audio initialization code and see what I can do when I have some more time (maybe this weekend) - so far that code just worked and I didn't have to modify it, so I'm not very familiar with it yet. |
|
it seems that sdl 2.0.7 does not change the resolution at all. Screenshots still have desktop resolution. what I can see is that audio is unavailable for a few seconds if resolution changes. switching back to desktop I can see a red cross over the loudspeaker symbol in the notification area. yamagi quake2 has the same 'problem', but a snd_restart fixes this. |
|
I hoped that I could reproduce the problem with my Gigabyte Brix system (also running Win10) that has intel Iris Pro 5200 Graphics and is connected via DisplayPort to a display that also has internal speakers.. Also: My GPU driver settings tool has audio settings that let me enable "audio without video" which means that audio is supposed to continue playing even if the display is turned off for energy saving. While audio worked for me even with this disabled, maybe enabling it might help on your machine? Oh, and you should have a stdout.txt in the directory you run the game in, can you attach it to a post here? |
|
Does the Brix system also use Intel Display audio or some Realtek High Definition audio? my system is a NUC6i5SYH running win10 Prof version 1709 (RS3) here are the relevant lines from stdout.txt the intel audio driver is version 10.26.0.1 I also did a test on my Win7 Laptop ( HD 530 Gfx controller) with the same monitor connected with DP. ----- Initializing OpenAL ----- |
|
I took a quick look at snd_system.cpp (not a c++ programmer myself) did some tests, started in windows mode after switch to fullscreen can't reproduce this though. most of the time I get this: ( blocked device?) are there any debug flags I can enable to get more useful output? |
I can't find such setting in Intel Iris Graphics Control Panel, in fact I don't see any settings regarding Audio. |
|
For me that part from stdout.txt looks like: I'm running Win10 1803 Build 17134.407 Your driver is probably newer than mine, because your GPU is a newer generation (this is a 5 year old Haswell CPU after all) The aforementioned Settings are under Display -> Audio Settings (translated from German, might be called slightly different) BTW, my display audio stopped working once I switched my display from DP input to DVI-D input (my big desktop PC is connected to the same display via DVI) and hasn't recovered yet. |
|
Does |
|
looking at This Audio without Video setting has been removed. I think it does not make sense, because for HDMI and DP you need video to be able to transfer audio data. DP / DVI-D issue, you could try to disable/enable the display audio device in device manager. This should bring back your audio device over DP connection. Yes the whole Intel Display Audio thing is a real PITA. |
|
Ok, it's a pity reloadEngine doesn't work. Problem is that apparently the integration of OpenAL into Doom3 (which as AFAIK been done by Creative Labs after they extorted id Software into supporting EAX sound effects with their infamous "Carmack's Reverse" patent) isn't super clean. Many sound-related types that were originally meant to be independent of the hardware (so closing/reopening the device wouldn't affect them) now have OpenAL handles in them that become invalid when re-opening OpenAL.. so I fear I can't fix this issue easily :-/ (I might take another shot later today, but I'm not too optimistic about it right now) BTW, about that excerpt of stdout.txt you posted earlier: Is this what you get when sound is broken? So in case that stdout.txt was from a dhewm3 run with working sound (maybe in windowed mode), I'd like the same excerpt for the broken case :) |
|
it looks exactly the same because sound is initialized before OpenGL. So the switch to a lower resolution happens after OpenAL already aquired the audio device. Is it possible to initialize opengl before openal? here is a start with fullscreen then in main menu I opens console: game crashed after exit. |
|
one more thing, |
|
yeah, I guess reloadEngine shouldn't really be used after all. it's all messy and complex :-/ |
|
I've found this, https://github.com/kcat/openal-soft/pull/237 |
|
Initializing OpenGL first and audio second is potentially a bad idea on Linux. OpenGL usually creates threads for background processing (either compiling shaders or building command buffers). OpenAL on the other hand might intialize PulseAudio which can fork the process. The combination of threads and forking can potentially deadlock though in this case it probably won't if you haven't issues any GL commands yet. Reinitializing audio in the middle of game might also bring the same problem. This is somewhat theoretical since I've never actually seen this in the wild but you still want to be careful. |
|
Do you have details on the "PulseAudio can fork the process" thing? Sounds incredibly error-prone |
|
No details, just saw it once in my Valgrind trace when debugging some program which used libpulse. Not sure under which exact conditions it does that. |
|
Maybe it does fork()+exec() to start the pulse demon if it isn't running? |
|
That's possible. I have computers both with and without PulseAudio and don't remember which it was. If you want to find out you could run some experiments, I don't currently have the time. |
|
Ok, I tried to implement a workaround last weekend, but didn't really get it anywhere near stable, so I'm sorry, but this issue won't be fixed anytime soon :-/ Have you considered just buying a cheap USB soundcard (I think you can get reasonable ones for ten to fifteen Dollars) and plug your speakers/headphones in there to avoid this broken display audio mess? |
|
thanks for trying. It's not that important. I wanted to have this issue documented. It's not the only system connected to this monitor, that's the reason why audio over HDMI or DP is so handy ;) . A workaround is to change desktop resolution before starting the game. I can also use a headphone, than audio device is realtek something. Issue seems to be in openal-soft, I found at least two pull requests. And today I found this entry in Intel's community forum. According to this, it's pretty normal that there is an up to 8 seconds long audio loss. Applications should recover this issue. |
|
I can't believe this fucking arrogance of Intel - this shit seems to break tons of games and they insist that it's the applications fault, despite very well knowing that older games will never be patched :-( I also strongly doubt that "The fact that the same game runs on different hardware is most likely because they have a higher time defined for modeset." - how would a game work better if the device is down for an even longer time? It works because other drivers don't take down the audio device... |
|
I guess it makes sense in one case, if user switches display to another display device. Than the audio driver would need to aquire new device's capabilities first. But setting another resolution on the same device does not change the audio device at all. |
|
Even if it's another display device - in >90% of cases it'll still just have simple stereo speakers so nothing except for the name should change? |
DanielGibson
changed the title
|
It seems that Intel might finally address this issue in an upcoming driver release.
|
|
At least they finally acknowledge it - let's hope they indeed fix it in
the future!
And let's also hope they don't only fix it for the latest GPUs but also
for older ones that for some stupid reason use different drivers on
Windows, even though (back to Sandy Bridge IIRC) they all use the same
driver on Linux so they can't be all that different..
|
|
AFAIK only win10 drivers for Skylake or newer core generations are affected. I guess this will take some more time before Intel might provide a solution. Issue was not listed in last two driver's release notes. |
OpenAL devices can disconnect, and with some luck they're back after a few seconds. This especially seems to happen with Intels Windows GPU driver and display-audio when switching the resolution or enabling fullscreen, see #209 Now a disconnect is detected and we try to reset the device for 20 seconds, hoping it comes back. This needs at least openal-soft 1.17.0 and might need 1.20.0 to actually work.
|
I think I have a workaround for this - can you please test dhewm3-oal-fixes.zip ? |
OpenAL devices can disconnect, and with some luck they're back after a few seconds. This especially seems to happen with Intels Windows GPU driver and display-audio when switching the resolution or enabling fullscreen, see #209 Now a disconnect is detected and we try to reset the device for 20 seconds, hoping it comes back. This needs at least openal-soft 1.17.0 to build and 1.20.0 or newer to actually work. Also added missing stub functions in openal_stub.cpp (used by dedicated server so it doesn't have to link libopenal)
|
I can confirm this build does indeed restore audio almost instantly after a mode switch. |
|
Awesome, thanks for testing! :) |
OpenAL devices can disconnect, and with some luck they're back after a few seconds. This especially seems to happen with Intels Windows GPU driver and display-audio when switching the resolution or enabling fullscreen, see #209 Now a disconnect is detected and we try to reset the device for 20 seconds, hoping it comes back. This needs at least openal-soft 1.17.0 to build and 1.20.0 or newer to actually work. Also added missing stub functions in openal_stub.cpp (used by dedicated server so it doesn't have to link libopenal)
|
This fix in master, but I have another OpenAL related fix that needs testing, see #296 There you can also get Windows binaries for testing that include all the OpenAL fixes of the build linked above, the aforementioned timing fix and latest changes from master. |
|
Hi I'm finding this issue on Ubuntu 20.04 x86_64 running on an old Intel NUC which uses a Intel HD Graphics 4000 (IVB GT2) with a Core i5-3427U CPU connected to monitor with sound via HDMI. When I run in windowed mode I get sound ok. In fullscreen I get no sound. The console the reports the following: I'm running latest commit from master. Thanks for any help. |
|
Try building latest openal-soft (1.21.0 or from git) yourself, that might work better. |
|
Ok thanks heaps. I will give that a try |
|
Thanks @DanielGibson I can confirm that openal-soft 1.21.1 fixed the lack of audio in fullscreen for me |
OpenAL devices can disconnect, and with some luck they're back after a few seconds. This especially seems to happen with Intels Windows GPU driver and display-audio when switching the resolution or enabling fullscreen, see dhewm#209 Now a disconnect is detected and we try to reset the device for 20 seconds, hoping it comes back. This needs at least openal-soft 1.17.0 to build and 1.20.0 or newer to actually work. Also added missing stub functions in openal_stub.cpp (used by dedicated server so it doesn't have to link libopenal)
following problem with latest stable 1.4.1 and with the new 1.5.0-rc1:
audio device is Intel Display audio
If game is configured to a lower fullscreen resolution ( 1920x1080) than the desktop (2560 x 1440 ) then audio output is not possible. seems to be sdl related, because audio works in this configuration with sdl version <= 2.0.7
Audio works if I set screen resolution same as desktop, or if game is in a window.
I tried to restart audio with s_restart but no luck so far. Is it possible to implement a proper audio restart procedure, or delay audio initialisation for a few seconds after switching resolution?
It looks like audio device is not available for a few seconds if screen resolution changes.
system is win10.
The text was updated successfully, but these errors were encountered: