Ivestigate "idSoundCache: error unloading data from OpenAL hardware buffer"

[bibendovsky]

Could happen inside idSoundSample::PurgeSoundSample. May crash the application on transition between levels.

[Kappa971]

This "bug" is strange (well with Doom 3 I don't expect anything else). It doesn't happen to everyone because otherwise many would write about this problem. It happened to me with Host OpenAL on Windows 10, it doesn't happen with X-Fi Titanium on Windows 11 but it happens on Windows 10 and it happens with Titanium HD on Windows 11. It also happens with OpenAL Soft. Apparently, for some with Host OpenAL it works fine. Not having found solutions about it, I found two video guides regarding Ollydbg, I managed to bypass the check in the Doom 3 executable (I have no experience with it) by jumping directly to the part of the code where the game goes if there is no OpenAL error. I'm not saying this is the best solution, it definitely isn't, but it's the only one I've found, but I don't know how much memory the game is wasting (the game crashed only once and maybe it has nothing to do with this), I was able to complete the main game and the expansion without any problems.

[mirh]

Random speculation entails W10 is at fault.

[Kappa971]

I don't know with which version of Windows 10 this error came out. It could simply be another OpenAL bug in this game. No other Id Tech 4 game has this problem.

[mirh]

Or it could also be people being dumbasses. Still, it seemed worth pointing out.

[bibendovsky]

Made Doom 3 build to log necessary OpenAL activity. Logs everything into file idt4_d3_bug_003_log.txt. The logs opens and closes for each message to ensure it will be written before a crash.

[Kappa971]

Made Doom 3 build to log necessary OpenAL activity. Logs everything into file idt4_d3_bug_003_log.txt. The logs opens and closes for each message to ensure it will be written before a crash.

I used this build of Doom 3. To see the OpenAL error, just load one level and then another (it isn't necessary to play an entire level). This is the log: idt4_d3_bug_003_log.txt

[bibendovsky]

I used this build of Doom 3. To see the OpenAL error, just load one level and then another (it isn't necessary to play an entire level). This is the log: idt4_d3_bug_003_log.txt

Thank you. So it is, sometimes the buffer is deleting before it was detached from a source.

Line 5497: [I][it02oj41] Attach buffer 237 to AL source 1.
...
Line 25777: [I][fg6xhybr] Delete AL buffer 237.
...
Line 25783: [I][7mnmj1yl] Detach buffers on AL source 1.

[bibendovsky]

Updated the build to stop AL source when necessary.

[Kappa971]

Updated the build to stop AL source when necessary.

Thanks @bibendovsky, the problem seems to be solved! I loaded level 3, then level 4 and finally level 2, no OpenAL errors. This is the log: idt4_d3_bug_003_log.txt

Will the fix be added to eaxefx_app_patcher?

[bibendovsky]

Another update. It removes all the logging previously added. If there is no the error message in the console and no other problems with audio, I will merge the changes in the source port and will try to create the patch.

[Kappa971]

Another update. It removes all the logging previously added. If there is no the error message in the console and no other problems with audio, I will merge the changes in the source port and will try to create the patch.

I played the entire level 3 without any problems. The transition from level 3 to level 4 didn't cause any OpenAL errors.

EDIT This source port I guess would allow you to understand what the volume control of the game menu does. As already explained in the other discussion, below a certain threshold (from -7db down) the game mixer "goes crazy", with the volume of the weapons that is no longer decreased in step with the ambient/voices volume, with the result that the weapons become very loud compared to the rest. The patch present in eaxefx_app_patcher only increases the threshold (maybe -2db, I don't remember) with which this bug comes out (but it remains useful with OpenAL Soft where there is no need to mess with game volume, as Windows mixer/OpenAL Soft avoids sound clipping).

I don't think it's related to OpenAL because it happens even with EAX disabled.

[mirh]

It's about openal buffers, so.. it seems pretty much something with openal. If you were to set s_useOpenAL to 0 I don't think you'd have any of these nuisances.

[Kappa971]

It's about openal buffers, so.. it seems pretty much something with openal. If you were to set s_useOpenAL to 0 I don't think you'd have any of these nuisances.

This

EDIT This source port I guess would allow you to understand what the volume control of the game menu does. As already explained in the other discussion, below a certain threshold (from -7db down) the game mixer "goes crazy", with the volume of the weapons that is no longer decreased in step with the ambient/voices volume, with the result that the weapons become very loud compared to the rest. The patch present in eaxefx_app_patcher only increases the threshold (maybe -2db, I don't remember) with which this bug comes out (but it remains useful with OpenAL Soft where there is no need to mess with game volume, as Windows mixer/OpenAL Soft avoids sound clipping).

I don't think it's related to OpenAL because it happens even with EAX disabled.

is not about this issue. This bug is solved, just wait for the fix to be implemented in eaxefx_app_patcher or use this source port.

What I'm talking about here is about the problem I described to you in the other discussion where I asked you to do a test. The volume bug described above also occurs with EAX disabled. With EAX disabled, s_useOpenAL is 0, so it's using DirectSound (I guess).

The OpenAL error is fixed, so I will not write any further comments here that may cause confusion, I only wrote it if @bibendovsky wants to investigate the volume control as well (but I would understand if he did not, they should have assumed him at Id Software, Doom 3 doesn't would have had all these bugs 😁).

[bibendovsky]

Added test build for the patcher.

The OpenAL error is fixed, so I will not write any further comments here that may cause confusion, I only wrote it if @bibendovsky wants to investigate the volume control as well (but I would understand if he did not, they should have assumed him at Id Software, Doom 3 doesn't would have had all these bugs 😁).

I'll see into this. If the fix won't be complex I'll will add it to the patcher, otherwise only to the source port.

[Kappa971]

Added test build for the patcher.

I'll try it tomorrow, thanks @bibendovsky.

[bibendovsky]

Fixed in v1.0.8.