Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intel Display-Audio sucks (was: no audio with sdl >2.0.7)

Closed
j4reporting opened this issue Nov 19, 2018 · 35 comments
Closed

Intel Display-Audio sucks (was: no audio with sdl >2.0.7) #209

j4reporting opened this issue Nov 19, 2018 · 35 comments

Comments

@j4reporting
Copy link

j4reporting commented Nov 19, 2018

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.

@DanielGibson
Copy link
Member

DanielGibson commented Nov 19, 2018

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)..
So apparently SDL > 2.0.7 switches the resolution in a different way than before, and that new way disables your intel display audio device for a few seconds?

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.

@j4reporting
Copy link
Author

j4reporting commented Nov 19, 2018

it seems that sdl 2.0.7 does not change the resolution at all. Screenshots still have desktop resolution.
I don't know if it's just a frame buffer stretched to desktop size. Game reports the configured lower resolution. EDIT: r_mode 7 is still rendered 16:9 2560x1440 with no visible aspect issues. /EDIT

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.
Usually normal status is restored after a few seconds.

yamagi quake2 has the same 'problem', but a snd_restart fixes this.
quakespasm same issue.

@DanielGibson
Copy link
Member

DanielGibson commented Nov 24, 2018

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..
But it seemed to work, the audio just started playing after changing the resolution, the audio device wasn't gone or anything.
What kind of intel GPU do you have? Are you running the latest drivers? How is your display connected?

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?

@j4reporting
Copy link
Author

j4reporting commented Nov 24, 2018

Does the Brix system also use Intel Display audio or some Realtek High Definition audio?
What win10 version did you test on?

my system is a NUC6i5SYH running win10 Prof version 1709 (RS3)
Monitor is connected with DP but a test using HDMI showed same issue.

here are the relevant lines from stdout.txt
----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'OpenAL Soft on DELL U2518D (Intel(R) Display Audio)'
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.19.1
OpenAL: found EFX extension
OpenAL: found 256 hardware voices
----- Initializing OpenGL -----
Initializing OpenGL subsystem
Using 8 color bits, 24 depth, 8 stencil display
OpenGL vendor: Intel
OpenGL renderer: Intel(R) Iris(R) Graphics 540
OpenGL version: 4.5.0 - Build 25.20.100.6373

the intel audio driver is version 10.26.0.1
Video driver is the latest version. I had video driver 24.20.100.6286 installed when I reported the issue.

I also did a test on my Win7 Laptop ( HD 530 Gfx controller) with the same monitor connected with DP.
And here audio works. It's muted for few seconds but recovers automatically.
So maybe it's an issue with win10 1709 release or a combination with this win10 version and the installed drivers.

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'OpenAL Soft on DELL U2518D (Intel(R) Display-Audio)'
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.19.1
OpenAL: found EFX extension
OpenAL: found 256 hardware voices
----- Initializing OpenGL -----
Initializing OpenGL subsystem
Using 8 color bits, 24 depth, 8 stencil display
OpenGL vendor: Intel
OpenGL renderer: Intel(R) HD Graphics 530
OpenGL version: 4.4.0 - Build 21.20.16.4860

@j4reporting
Copy link
Author

j4reporting commented Nov 24, 2018

I took a quick look at snd_system.cpp (not a c++ programmer myself)
it would be interesting to get an idea what devices are available after a resolution switch

did some tests, started in windows mode
listSoundDecoders gives this output: (while in title screen)
]listSoundDecoders
0 decoding 7% OGG: sound/musical/d3theme.wav
1 decoders
0 waiting decoders
1 active decoders
0 kB decoder memory in 0 blocks

after switch to fullscreen
]listSoundDecoders
0 decoding 4% OGG: sound/musical/d3theme.wav
1 decoders
0 waiting decoders
1 active decoders
0 kB decoder memory in 0 blocks
]listSoundDecoders
0 decoding 25% OGG: sound/musical/d3theme.wav
1 decoding 0% OGG: sound/musical/d3theme.wav
2 decoders
0 waiting decoders
2 active decoders
0 kB decoder memory in 0 blocks
]listSoundDecoders
0 decoding 31% OGG: sound/musical/d3theme.wav
1 decoding 7% OGG: sound/musical/d3theme.wav
2 decoders
0 waiting decoders
2 active decoders
0 kB decoder memory in 0 blocks

can't reproduce this though.

most of the time I get this: ( blocked device?)
]listSoundDecoders
0 decoding 100% OGG: sound/ed/gui/chirpconnect.wav
1 decoders
0 waiting decoders
1 active decoders
0 kB decoder memory in 0 blocks

are there any debug flags I can enable to get more useful output?

@j4reporting
Copy link
Author

j4reporting commented Nov 24, 2018

Also: My GPU driver settings tool has audio settings that let me enable "audio without video"

I can't find such setting in Intel Iris Graphics Control Panel, in fact I don't see any settings regarding Audio.
Just Display, VIdeo, 3D, Power and 'Options and Support' are available

@DanielGibson
Copy link
Member

DanielGibson commented Nov 24, 2018

For me that part from stdout.txt looks like:

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'OpenAL Soft on 24EB23 (Intel(R) Display-Audio)'
OpenAL: found device 'OpenAL Soft on Digitalaudio (S/PDIF) (High Definition Audio-Gerät)'
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.19.1
OpenAL: found EFX extension
OpenAL: found 256 hardware voices
----- Initializing OpenGL -----
Initializing OpenGL subsystem
Using 8 color bits, 24 depth, 8 stencil display
OpenGL vendor: Intel
OpenGL renderer: Intel(R) Iris(TM) Pro Graphics 5200
OpenGL version: 4.3.0 - Build 20.19.15.5058

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)
intel-graphics-audio

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.
I guess that's the reason why instead of using display audio I connected a cable from the Brix' headphone jack to my displays line-in - that at least works reliably.

@DanielGibson
Copy link
Member

DanielGibson commented Nov 25, 2018

Does reloadEngine instead of s_restart work better? It seems to completely restart OpenAL (and everything else)

@j4reporting
Copy link
Author

j4reporting commented Nov 25, 2018

reloadEngine does not work, because during reload the screen will change back to desktop and than back again to the configured fullscreen resolution.

looking at snd_system.cpp it seems like a s_restart does not release and reopen the aldevice at all.

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.

@DanielGibson
Copy link
Member

DanielGibson commented Nov 25, 2018

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?
Because I would have expected it to not find any device (or at least not that device) in that case..
I mean, if initializing OpenAL failed I maybe could keep on trying for 20sec or so until it succeeds, but if it succeeds and doesn't work anyway that's not possible..

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 :)

@j4reporting
Copy link
Author

j4reporting commented Nov 25, 2018

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

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'OpenAL Soft on DELL U2518D (Intel(R) Display Audio)'
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.19.1
OpenAL: found EFX extension
OpenAL: found 256 hardware voices
----- Initializing OpenGL -----
Initializing OpenGL subsystem
Using 8 color bits, 24 depth, 8 stencil display
OpenGL vendor: Intel
OpenGL renderer: Intel(R) Iris(R) Graphics 540
OpenGL version: 4.5.0 - Build 25.20.100.6373

then in main menu I opens console:

]listSoundDecoders 
  0 waiting OGG: sound/misc/idlogo_audio.wav
  0 decoding  18% OGG: sound/musical/d3theme.wav
2 decoders
1 waiting decoders
1 active decoders
0 kB decoder memory in 0 blocks
]s_restart 
Shutting down sound hardware
]reloadEngine 
============= ReloadEngine start =============
----- Game Map Shutdown -----
Shutting down sound hardware
idRenderSystem::Shutdown()
Shutting down OpenGL subsystem
----- Game Shutdown -----
----- Game Map Shutdown -----
Shutdown event system
----- Initializing File System -----
[deleted]
----- Initializing Decls -----
5206 strings read from strings/english.lang
Couldn't open journal files
execing editor.cfg
execing default.cfg
execing dhewm.cfg
couldn't exec autoexec.cfg
5206 strings read from strings/english.lang
----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'OpenAL Soft on DELL U2518D (Intel(R) Display Audio)'
OpenAL vendor: (null)
OpenAL renderer: (null)
OpenAL version: (null)
OpenAL: EFX extension not found
OpenAL: found 0 hardware voices
----- Initializing OpenGL -----
----- Initializing Game -----
gamename: baseDOOM-1
gamedate: Nov 12 2018
Initializing event system
...473 event definitions
Initializing class hierarchy
...142 classes, 191092 bytes for event callbacks
Initializing scripts
Compiled 'weapon_handgrenade::Lower': 729 ms
----- Compile stats -----
Memory usage:
     Strings: 79, 9648 bytes
  Statements: 67875, zd bytes
   Functions: 2109, 250532 bytes
   Variables: 147376 bytes
    Mem used: 2576440 bytes
 Static data: zd bytes
   Allocated: 3481696 bytes
 Thread size: zd bytes
...6 aas types
----- Initializing Session -----
============= ReloadEngine end ===============
]quit
----- Game Map Shutdown -----
Shutting down sound hardware
----- Game Map Shutdown -----
********************
ERROR: idSoundCache: error unloading 

game crashed after exit.

@j4reporting
Copy link
Author

j4reporting commented Nov 25, 2018

one more thing,
after a reloadEngine the command listSoundDecoders will crash the game.
nothing in stdout.txt and stderr.txt

@DanielGibson
Copy link
Member

DanielGibson commented Nov 25, 2018

yeah, I guess reloadEngine shouldn't really be used after all.
good point about initializing sound first and opengl second; not sure I can switch those - at least vid_restart currently works (after changing the resolution)

it's all messy and complex :-/

@j4reporting
Copy link
Author

j4reporting commented Nov 25, 2018

I've found this, https://github.com/kcat/openal-soft/pull/237

@turol
Copy link
Contributor

turol commented Nov 26, 2018

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.

@DanielGibson
Copy link
Member

DanielGibson commented Nov 26, 2018

Do you have details on the "PulseAudio can fork the process" thing? Sounds incredibly error-prone

@turol
Copy link
Contributor

turol commented Nov 26, 2018

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.

@DanielGibson
Copy link
Member

DanielGibson commented Nov 26, 2018

Maybe it does fork()+exec() to start the pulse demon if it isn't running?
Might be possible to do that in a "safe" way though, possibly with clone() instead of fork()?

@turol
Copy link
Contributor

turol commented Nov 26, 2018

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.

@DanielGibson
Copy link
Member

DanielGibson commented Dec 5, 2018

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?

@j4reporting
Copy link
Author

j4reporting commented Dec 5, 2018

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.

openal-soft pull requests
241
237

@DanielGibson
Copy link
Member

DanielGibson commented Dec 5, 2018

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 :-(
Also, I don't care what the HDMI standard tells them, I see no reason to take the audio device down. They can stop sending audio to the display for all I care, but the device itself should stay up?

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...

@j4reporting
Copy link
Author

j4reporting commented Dec 5, 2018

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.

@DanielGibson
Copy link
Member

DanielGibson commented Dec 5, 2018

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 DanielGibson changed the title no audio with sdl >2.0.7 Intel Display-Audio sucks (was: no audio with sdl >2.0.7) Jan 10, 2019
@j4reporting
Copy link
Author

j4reporting commented Sep 6, 2019

It seems that Intel might finally address this issue in an upcoming driver release.
Today I found this in the latest dirver's release notes under 'Known Issues'

Some games may not have audio when using Intel Display Audio in full screen mode when the resolution is different than what is set in Windows or Intel Graphics Command Center.

@DanielGibson
Copy link
Member

DanielGibson commented Sep 6, 2019

@j4reporting
Copy link
Author

j4reporting commented Nov 10, 2019

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.
Here is the link to Intel's support article.

DanielGibson added a commit that referenced this issue May 28, 2020
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.
@DanielGibson
Copy link
Member

DanielGibson commented May 29, 2020

I think I have a workaround for this - can you please test dhewm3-oal-fixes.zip ?

DanielGibson added a commit that referenced this issue May 29, 2020
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)
@j4reporting
Copy link
Author

j4reporting commented May 30, 2020

I can confirm this build does indeed restore audio almost instantly after a mode switch.
This workaround works much better than the current, more static workaround in yquake2.

@DanielGibson
Copy link
Member

DanielGibson commented May 30, 2020

Awesome, thanks for testing! :)

DanielGibson added a commit that referenced this issue Jun 1, 2020
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)
@DanielGibson
Copy link
Member

DanielGibson commented Jun 1, 2020

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.
Thanks in advance for testing! :)

@palmerj
Copy link

palmerj commented Dec 29, 2020

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:

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'Built-in Audio Digital Stereo (HDMI)'
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.19.1
OpenAL: found extensions for resetting disconnected devices
OpenAL: found EFX extension
OpenAL: found 256 hardware voices

WARNING: OpenAL device disconnected! Will try to reconnect..
WARNING: OpenAL device still disconnected! Giving up!

I'm running latest commit from master.

Thanks for any help.

@DanielGibson
Copy link
Member

DanielGibson commented Dec 29, 2020

Try building latest openal-soft (1.21.0 or from git) yourself, that might work better.
IIRC this wouldn't work with any version before 1.20

@palmerj
Copy link

palmerj commented Dec 29, 2020

Ok thanks heaps. I will give that a try

@drewwoods
Copy link

drewwoods commented Jun 25, 2021

Thanks @DanielGibson I can confirm that openal-soft 1.21.1 fixed the lack of audio in fullscreen for me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants