Sound buffers?

[wildweasel486]

One thing has always bothered me about id Tech 4 games - Doom 3, Quake 4, and Prey specifically; Wolfenstein doesn't seem to have this problem - and that's the way rapid-fire weapons sound. Under sustained fire, the machine gun, chaingun, and plasma rifle all sound as if they're "missing" their firing sounds every few shots. Other things suffer from this, too, like footstep noises. I suspect it's a problem with the sound buffer size and response times, but I can't find any console variables to set to fix it.

I'd asked about this on the Doomworld forums, but was directed to ask here instead; is there some oddity to the id Tech 4 sound engine at work here? I can confirm that it happens in both vanilla Doom 3 (Windows 1.3.1) and in a release build of dhewm3 from last week.

[Evilbaka]

I think it is specific software/hardware combination, since I stumbled into that error in related to Idtech GoldSource engine on some HL versions and Dreamcast version. But this is not the place for discussing HL, I think.

[wildweasel486]

Not necessarily, as I've experienced it on a number of different machines with wildly different hardware setups over the years.

[hemebond]

Apparently this is an issue with sound system synchronisation and has apparently been fixed in the Doom 3 BFG Edition.

[gabrielcuvillier]

Maybe you could try to tweak the "com_asyncSound" cvar to see if there is any differences (need to be done at compilation or startup time):

0: mix sound inline (in the main thread)
1: memory mapped async mix (separate thread, default on windows)
2: callback mixing (not sure if it is working)
3: write async mix (separate thread, default on Linux)

[hemebond]

Default was 3. No difference with 0 and 1. No sound at all with 2.

I did see mention of a cvar that could "fix" it but apparently it caused cutscene audio to desync.

[gabrielcuvillier]

Ok, this is maybe related to the specific OpenAL implementation being used also

[hemebond]

BTW, this is the comment that mentioned a variable for audio sync https://steamcommunity.com/app/208200/discussions/0/343786746010619195/#c343787920131961205

I also tried disabling vsync, com_preciseTic, and com_fixedTic but if it wasn't still running at ~60fps with the stutter, it was running too fast to tell.

This has always happened to me throughout Win XP and Win 10 and two different motherboards and two Soundblaster cards and happens now with the source port and 120 fps base.dll. I will test more. After playing awhile, it is quite immersion breaking to me since I am sound sensitive, especially when I have modded the weapon firing rates to be faster. However the 120+ fps now makes it worth dealing with!!!

[DanielGibson]

Is this even a bug?
As it happens with original Doom3 on Windows as well (with and without OpenAL), maybe it's supposed to sound like that and the weapons just stutter every few shots or shot in bursts or something?

[hemebond]

I don't think it's an issue in the BFG edition of the game. I don't have the BFG edition so I'm unsure if the difference in the game files or the engine.

It only affects the sound of the gun, not the actual shots.

https://youtu.be/CNRoOSmkMLI?t=182

No need to gaslight us over an obvious bug, DanielGibson. We know better being interested in modding a 15 year old game and this conspiracy is well out in the open to us. The real question is what are the sound coders trying to hide here and why are you helping them? It's been 15 years and the truth must come out!

[DanielGibson]

No need to gaslight us over an obvious bug, DanielGibson.

Mind your manners, @thoughtartist. This is your first and only warning.

[DanielGibson]

The fundamental problem is that sound is only updated around 10 times per second, by the async timer in the async thread: https://github.com/dhewm/dhewm3/blob/master/neo/sound/snd_system.cpp#L680-L688 (AsyncUpdate() basically does the same but with more complicated code):

unsigned int dwCurrentBlock = (unsigned int)( inTime * 44.1f / MIXBUFFER_SAMPLES );
// inTime is current Time in milliseconds since the game was started
// MIXBUFFER_SAMPLES = 4096 (it's a constant defined somewhere)
// 44.1f / MIXBUFFER_SAMPLES == 0.010766602
// ...
if ( dwCurrentBlock < nextWriteBlock ) {
	return 0; // !!!
}
// ...
currentSoundWorld->MixLoop( sampleTime, numSpeakers, finalMixBuffer );
// ...
nextWriteBlock = dwCurrentBlock + 1;

so only if inTime has increased enough since last successful update to increase dwCurrentBlock, currentSoundWorld->MixLoop(...); is called - that is the case roughly every 93 milliseconds (=> about 10 updates per second).
MixLoop() starts openal sounds and update ones already playing - for longer sounds streaming from .ogg files - and I think it also does sound effects or something, and calls into SIMD (SSE/Altivec/...) code. I think because of this streaming (decompressing chunks of data, MIXBUFFER_SAMPLES at a time) and the SIMD stuff (which needs correctly aligned buffers) this is only done every MIXBUFFER_SAMPLES samples. I'm not 100% sure which of these reasons (if any) are really relevant for the OpenAL backend, I assume with the software mixing code this was (even?) more important.

So imagine the gamecode tries to play a sound right after MixLoop() has been called - then can theoretically take up to 93 ms until MixLoop() actually tells OpenAL to play it!
And in practice it can even be a bit longer, because AsyncUpdateWrite() is called about every 16 milliseconds and if it's called one millisecond to early for MixLoop() to be called, the time MixLoop() gets called its 15 milliseconds late, which can cause delays of up to 108ms or so.. though those last 15-16ms don't make much of a difference at that point (but could be avoided with only small changes to the code).
And the actual delay drifts over time, due to the gamecode being updated every 16ms and MixLoop() (ideally) being updated every 92-94ms. For example, with the Machine Gun the delays were often like this:

delay: 80ms
delay: 76ms
delay: 39ms
delay: 17ms
delay: 13ms

delay: 90ms
delay: 52ms
delay: 32ms
delay: 28ms
delay: 8ms

delay: 66ms
delay: 62ms
delay: 41ms
delay: 20ms
delay: 15ms

delay: 75ms
... etc

(empty lines added to make those blocks more visible)
So one shot with high delay, then 4 more shots, each a bit less delay, then it starts again with high delay - and keep in mind that the MP shoots 10x/second => one shot every 100ms!
This leads to the shots sounding like bursts and it can happen that two sounds are played so quickly after another that it sounds like one sound, which makes it sound like one is dropped (I didn't actually observe this, but if it somehow happens that the gamecode "starts" two shot sounds between MixLoop() calls, that the second actually cancels the first and it's really dropped).

As a side-note (mostly to myself) that async thread thing is pretty broken, it tries to only get the AsyncTimer() callback called about every 16ms, but in fact it's called every millisecond, calls idCommonLocal::Async() and that function will then make sure things (incl. idSoundSystemLocal::AsyncUpdate()) are only called every 16ms.
So as idCommonLocal::Async() is in fact called every millisecond, it could just call idSoundSystemLocal::AsyncUpdate() every time instead of every 16ms, so it'll indeed be called every 92-94ms. But as I said above, that doesn't fix the main issue..

Unfortunately, I'm not sure how to fix this issue, I'd have to find out if this "only update every 4096 samples" stuff is really needed and if it is, work around it somehow, and otherwise call MixLoop() more often.
All in all the OpenAL backend has been hacked ontop the old sound backend and thus carries restrictions from the (apparently already sub-optimal) old software mixing backends :-/
Not sure when/if I get around to this, just debugging to get these insights took a lot of time..