@_mental_ & Graf
I'm on g3.2pre-333-gb1d1ac1.
"Áudio do vídeo Intel" is indeed the HDMI audio device as ibm5155 said. (it's portuguese for "Intel video's audio", in a literal/direct translation)
So, I disabled virtual memory. Instead of freezing, Windows showed me a window telling me to close GZDoom. Anyway, got some crash reports now. The first one was from putting a lot of "playsound *pain;"s in a single line (about 256) and executing that. That crashed it.
The other happened by doing that a single time again, but it only crashed after I tried to type in the console, IIRC.
One thing I should mention is that for some reason the log file in the crash reports is missing this line:
Code: Select all
>>>>>>>>>>>> Received AL error Invalid Operation (0xA004), oalsound.cpp:1519
This line only appeared after closing the ZDoom Very Fatal Error window. After that, it just output that line and froze instead of closing.
There were also times when it didn't crash and just started outputting this to the console whenever a sound was meant to play:
Code: Select all
>>>>>>>>>>>> Received AL error Out of Memory (0xA005), oalsound.cpp:1619
I'm pretty sure there's some memory leak either in OpenAL or in GZDoom's code for the OpenAL backend, because this doesn't happen in FMOD. (Tested in g2.3pre-4-g475077f. It did happen with the OpenAL backend in that too.)
I guess just playing normally would make it happen too... In fact, I've had GZDoom spam ">>>>>>>>>>>> Received AL error Out of Memory (0xA005), oalsound.cpp:1619" to the console while playing before.
It's just that spamming "playsound *pain;" in the console makes it leak memory faster.
@ibm5155
Yeah, I did test without sound. Using literally ANYTHING other than OpenAL didn't leak memory like that.
And no, I don't have anything like that installed. This is a clean install of Windows 10, no OEM crap. I also don't use bank software, so it wouldn't be that. (And I'm 16 anyway, so no bank accounts to use a bank program for, and I'm the only person who uses this computer)