Sound-playing things warped to player have jumpy audio

[Nash]

https://www.dropbox.com/s/j7fu3cdavz3ar ... p.pk3?dl=0

This uses ACS to attach a little medikit-looking-thingy to the player - using Warp with interpolation - that continuously emits a rain sound.

ZDoom 2.8.1 = Normal expected behavior
zdoom-2.9pre-746-gdb86385 = audio jumps erratically between left and right speakers when the player is moving.

You have to move around to trigger the bad effect. In 2.8.1, no matter how much you move, the audio stays centered to you.

[Graf Zahl]

I can't hear anything strange. How precisely does this manifest itself?

[Nash]

Very severely. Are you using headphones or regular computer speakers? It's very obvious even on my speakers, I imagine if you wear headphones, the bug will be even more obvious. On my audio interface's VU meter, I could literally see the signal jump hard left and hard right in the stereo field.

Some additional info:

Using Fmod sound system
Doesn't happen in ZDoom 2.8.1, happens on the latest ZDoom Git build
I'm using default sound settings that come with ZDoom
You have to really move around quite a bit in the level, just standing still won't trigger it

Here's a short video that demonstrates the bug very clearly. I generated a fresh INI before recording this. I know you hate videos in bug reports but trust me, you WILL hear the audio problem when you view this.

[Graf Zahl]

I can hear some distortion in the video but since the rain sound is essentially mere noise it doesn't help much. I tried a few different sounds but I can't seem to reproduce it.

[Nash]

I chose the rain noise because a seamlessly looping and continuous audio signal would make it easier to detect the sound level changes, rather than transiently signals like an explosion or a monster cry which would have attack and decay intervals. Anyway, the audio waveforms in the above picture should confirm precisely what's going on. Stereo audio track on the top is the latest ZDoom Git build, the bottom one is ZDoom 2.8.1. You can clearly see the audio in the bottom one is 100% seamless, while the audio on the top has not only tiny little cuts and gaps, but also In some cases an entire channel's amplitude is almost completely muted (this is what I meant by the audio jumping between left and right channels).

I made a modified version that emits a cyberdemon sight sound instead, in case for some reason your hearing's more suited to that. -> https://www.dropbox.com/s/ublhxa6qz4u6l ... y.pk3?dl=0

[Nash]

Additionally, I found out that where the audio gets "stuck" in the stereo field depends on the last direction of movement you took before the player stopping. If I strafe left (no forward movement), when the player stops moving, the audio will be stuck to the left channel. Vice versa for movement to the right. Forwards and backwards movement would USUALLY re-center the audio, but not always. It is additionally possible to trigger the erratic left/right sound bug even by just continuous forward/backward movement.

[Graf Zahl]

Since I have some problems with such sound testing, can you try the following:

In s_sound, after line 701 :

Code: Select all

*pos = { (float)posi.X, (float)posi.Z, (float)posi.Y };

add the following:

Code: Select all

					FVector3 comp = FVector3(listenpos.X, listenpos.Z, listenpos.Y);
					if (pos->ApproximatelyEquals(comp)) *pos = comp;

and see if that makes any difference?

[Nash]

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

[Graf Zahl]

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.

[Nash]

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

[Graf Zahl]

No problem.

[Nash]

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?

[Graf Zahl]

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.

[Nash]

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

[Graf Zahl]

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.