ZDoom

Would it instead be possible to have an explicit HeadRelative flag for such sounds, rather than just guessing if it's "close enough"? There was a similar issue previously where even though the sound and listener positions were set the same, because the values were so large some of internal transforms applied to the sound position was creating floating point rounding errors on some systems/compilers, which were larger than the approximately-zero allowance of 1.19209290e-07 (this was fixed on OpenAL Soft's side by changing to doubles instead of floats for certain calculations, thereby reducing the rounding error, but having a clear indication of which sounds should be head-relative would be a better fix).

I can otherwise make a similar fix for the OpenAL backend as was applied to the FMOD backend, though it feels kludgy.

With a homebrew build of ZDoom (generated with FMod disabled in CMake) and running the audio in OpenAL mode, the example file still exhibits the broken behavior. Checkout is the latest (with the fixes Randi just commited). So it looks like in OpenAL, this bug still happens...

No problems with FMod, the bug has been fixed for that path.

The OpenAL backend has no concept of a 'head relative' sound, so it may behave differently. Have you tested there, too?

Thank you Randi!

I noticed that the change is only in fmodsound.cpp. Would this change propagate to OpenAL as well or do I have to fix that separately?

Ah, that's why all my attempts to solve this at the higher level had so bad results...

I decided to close this because with an attenuation of 20 this is not fixable with ACS using another numeric system than the rest of the engine.

That really makes no sense. I think Randi needs to take a look here. I've never seen this large distances between the player and the sound source in my tests.

2048 for EQUAL_EPSILON seems to have eliminated the problem completely. I turned on turbo at maximum speed (well, the fastest the DoomPlayer can go any way) and frantically waved the mouselook left, right, up and down while running - sound stays perfectly seamless.

I only tested it with my demo file, I have absolutely no idea what side effects changing that constant may have, considering it's such a huge difference (from 65k to 2k).

What's so hard about that function? All you need to do is fiddle around with EQUAL_EPSILON so that I know what the smallest value is that works. 1/65536, as it is now, seems to be insufficient for sound.

I took a look at ApproximatelyEquals and unfortunately I don't really know anything about working with vector math (I mostly just follow tutorials and don't even fully understand what I've been doing to be honest), on top of that I don't even understand what's going inside that CalcPosVel function.

Is there any way you can visualize the volume waveforms coming out of ZDoom to check this bug? Like recording a "What U Hear" / stereo mix of the ZDoom session while you test the example file? Failing that, I'm really not sure what else to suggest as I'm running out of ideas on how to help solve this problem...

Or perhaps you could just tell me what exactly to modify and where and I'll just keep plugging in some numbers through trial and error until the problem is gone?

No problem.

I haven't followed up with this yet because I'm super swamped with work today... I can only get to this in around 6 - 8 hours from this post... don't close this yet

Hm. That sounds like FMod is extremely sensitive to coordinate exactness.

You can look up that ApproximatelyEquals function and play around with its values until you find something that sounds ok. Don't worry, that thing is never used anywhere else, so it won't disrupt any gameplay features.

It does help, but only a little. The audio cuts definitely happen less with that code.

EDIT: I mean the cuts happen less frequently while moving around. Definitely not as bad as before. But still not 100% seamless like 2.8.1...