[Fixed] 4.5.0 Audio "pops" again

[Enjay]

I know that there have been a few threads about audio pops and looping issues under different conditions since 4.5.0 came out and most of these have been put to bed with tags of "user error" and so on, but I am convinced that something has changed that makes these kinds of issues more obvious.

There has always been the possibility of getting an audible click or pop when lots of copies of the same sounds are played in short succession but I have been noticing it much more with 4.5.0 than with previous versions. A typical example where I might hear it is when there is a row of health bonuses that can be run across quickly causing lots of pickup sounds to be played close to each other.

Is there anything that has changed in the sound code between the last two official versions that could be causing this?

I haven't posted an example because it happens a lot with different mods and different sounds. It does seem to happen mostly with mods that have custom sounds though.

[SanyaWaffles]

We did exactly what was told of Nash and Chris for SHDX and we notice a pop still, even with zero-point phase loop points accurate to the sample. It tends to go away after a loop or two though. Our issue was all ready closed though, so we decided just to press on until we could find out more.

The fact other people have been noticing this as a problem makes me think something changed between 4.4 and 4.5 in terms of the sound code, but due to various refactors from Raze, it's really hard to pinpoint exactly what.

[Enjay]

Here's an example with some evidence. I think that the problem may have crept in before 4.5.0 though because I was able to get the clicks with 4.4.2

Using this file: http://www.aspectsweb.co.uk/enjay/doom/ ... Clicky.pk3

GZDoom sounds like this in 4.3.3 when running down the corridor: http://www.aspectsweb.co.uk/enjay/doom/ ... /4.3.3.wav

and it sounds like this in 4.5.0 http://www.aspectsweb.co.uk/enjay/doom/ ... /4.5.0.wav using exactly the same configs.


Given that I was able to capture the sound with GoldWave recording "Stereo Mix" from my sound card's output directly, the explanation that it has something to do with speakers doesn't seem to cover it.

[Rachael]

Moved to Audio/Music bugs.

I did not hear a difference between the two sound samples, so either my audio hardware isn't as sensitive or my hearing isn't or maybe both. But others on this forum are far more expert than me on this issue so I just have to defer to them, as before.

My hypothesis on this particular report though, is the speakers are being pushed to their limit and it's causing audio clipping. But again - I am no expert so this is only a guess.

[Nash]

The clicking is very obvious in the second wave file, yes. Something is definitely up, no doubt. Unfortunately that's about all I can offer here - I wouldn't know where to begin looking, code-wise. :(

[Rachael]

Maybe it has to do with the now unlimited sounds per channel?

[Enjay]

I'm surprised that you can't hear a difference - it's very obvious to me. On the 4.5.0 WAV, at about 3 seconds in (after the first few pickup sounds) there is a horrible, and pretty loud click with every subsequent pickup. It can be seen quite clearly on the wave form:


4.3.3 top, 4.5.0 bottom

As I said, I don't think it can be a speaker issue because the WAV files were recorded directly from the output of my sound card - the recorded sound had not gone via the speakers when it was captured.

[Rachael]

Huh that is interesting. Yes, wave forms like that definitely would cause a bit of a pop. But I have no idea what causes that.

[phantombeta]

Just to be sure - What happens if you replace openal32.dll with a copy from an older release, say, 4.3.3? (It has to be one from before 4.4.0)
Does the problem persist? Or does it get fixed?

[Nash]

Running Enjay's example file on my computer, the problem can be reproduced 100%. Tested it with a fresh INI and homebrew GZDoom g4.6pre-38-g499df0382. So it's not anything system or hardware dependent.

(you can hear the problem more clearly if you turn off the game music)

[phantombeta]

Just to be sure - What happens if you replace openal32.dll with a copy from an older release, say, 4.3.3? (It has to be one from before 4.4.0)
Does the problem persist? Or does it get fixed?

Just tested this myself with the example file... (Didn't notice there was one until Nash's post )
Interestingly enough, it does seem to change what happens. 4.5.0 with 4.3.3's OpenAL32.DLL still seems to erroneously kill the sound too early, but it consistently returns the sample down to 0.

4.5.0 with the OpenAL32.DLL from 4.5.0:


4.5.0 with the OpenAL32.DLL from 4.3.3:


So this might be an issue with both GZDoom's sound system and OpenAL-Soft.

[Metal Neon]

Idk what version of OpenAl-Soft each version of GZDoom uses, but I do know that it's been fairly buggy ever since the release of 1.20.0

I know they released 1.21.0 a while back that seems to be more stable, but I've read of issues with it on some games still.

If 4.3.3 uses 1.19.1 then that would probably explain at least part it of.

So this might be an issue with both GZDoom's sound system and OpenAL-Soft.

[Rachael]

There have been some major sound changes since 4.4.0 also, though, so simply swapping out to the old OpenAL-Soft likely will not solve all problems. I think as Phantom already said, it's both.

[Enjay]

Just to be sure - What happens if you replace openal32.dll with a copy from an older release, say, 4.3.3?

Testing this myself - using 4.5.0 but with 4.3.3's openal32.dll, I do not get the clicks with the example file.

So, that would certainly seem to be part of the problem. Whether there is more going on, as Rachael and Phantom suggest, I honestly can't say because after a few trials, I'm struggling to hear anything amiss when using the 4.3.3 openal file.

[Chris]

It almost looks like OpenAL Soft's click/pop prevention isn't working as well as it should. I mean, it seems to be doing exactly what it should -- I can see in the 4.5 waveform where the sound stops mixing at the start of an update, and then slowly fades the DC offset back to 0 over the update (rather than immediately snapping to 0, which as noted in the other thread, would just as well cause clicks/pops). I don't know if the still-audible pops are a limitation of the method, or if the fade should be more logarithmic instead of linear, or whether it's acting too fast or too slow, or something else unrelated that the old version just hides better.

It doesn't seem to be so bad for me, though. When I run your test map, if I listen closely I can make out a small bit of popping sometimes, which is consistent with all my testing thus far; in GZDoom and other OpenAL apps, clicks/pops from sounds being stopped are all but gone, unless I listen really closely I can sometimes hear it a little. But I do hear it more pronounced in your recordings, for some reason.