Full-volume monster sounds are not normalized

[phantombeta]

For some reason, full volume monster sounds are not getting normalized anymore. They end up horribly loud and clipping. 3D sounds get normalized just fine, however.
Reverting to an older OpenAL32.dll build from a previous release fixes it. (and using the DLL from 4.4.2 with that previous release carries the issue over to it)
(I don't do the sound code, so I have no idea if this is an OpenAL Soft bug or a breaking API change that needs to be accounted for by GZDoom.)

Steps to reproduce:

• Start GZDoom with NUTS.
• Start the game.
• Do "kill monsters".

Extremely loud Spider Mastermind and Cyberdemon death sounds should now be playing absurdly loudly due to overlapping with no normalization.

[Edit]

Excuse me


What the fuck.
(Pay attention to where the "Max volume" slider thingy is)

[Graf Zahl]

The way you describe it sounds like an OpenAL bug.

Paging Chris...

[Nash]

I suppose it's fair to warn that anyone reading this and wants to repro this, please turn your volume down or suffer hearing and/or equipment damage... :D

[Graf Zahl]

I'll surely ship the upcoming releases with the old DLL unless this gets fixed first.

[sinisterseed]

Good grief lol. That's one way to ignore sound settings...

It seems newer versions of OpenAL don't play well with GZDoom at all. This is not the first time I'm seeing reports related to the newer .dlls here. Well, at least Raze survives this, at least for now. I don't recall seeing similar behavior there.

[Graf Zahl]

That's because you cannot trigger this edge case easily there. Since it's the same sound system, if you were able to you'd get the same effect.

This is not the first time I'm seeing reports related to the newer .dlls here.

Same here. I have seen some reports of sounds musbehaving, too.

[sinisterseed]

Na, I have an idea actually.

Spawn 100 Rippers in SW and kill them all. That should answer the question. But do we even have a "kill monsters" equivalent there, let alone a way to spawn enemies?

[Rachael]

We'd have to make one but ultimately all you'd have to do with it (maybe, I think?) is iterate through each sprite, check if it's a monster and has health, and set it to 0. Build games usually don't have as solid of a concept of states and flags as Doom does, so changing a creature's health might be enough to kill or revive them.

[Graf Zahl]

In Duke that is correct. Its entire state management is 100% code with no data tables at all. The other games are far more robust with their state management.

[Chris]

OpenAL Soft doesn't do anything special with regards to the volume for local/"full-volume" or 3D sounds, other than the usual distance attenuation for 3D sounds. It uses the volume it's given as the base, they all get mixed into a floating-point buffer with the appropriate filters in place, then prior to writing to the system device, optionally applies a compressor/limiter to reduce the volume around samples outside of the -1...+1 range that would otherwise need to be clipped.

At least Windows seems to have its own limiter too -- something other people have previously complained about around here, loud sounds being compressed before OpenAL Soft even got its limiter, because it didn't pre-clip out-of-range floating point samples before giving them to the system. Since OpenAL Soft got its limiter, the logic for when it would enable it by default has been tweaked, to try to be more sensible. Some versions would always have it on by default, while more recent versions would have it off for floating point sample output by default, in case the system wants do its own processing with the full range samples. What is the old version of OpenAL Soft that works, and the newer one that has the issue (snd_status in the console should say)?

Windows, accepting floating point samples, would have it off by default in newer versions. I guess its possible Windows' built-in limiter is itself limited in how much it can compress the output (whereas OpenAL Soft's limiter shouldn't have a problem at least up to +60dBFS, or 1000x linear amplitude; but even then it might still keep up, I'm not completely sure). A user can of course forcefully enable/disable it themselves with the config file or the alsoft-config utility. It can also be controlled by the app using the ALC_SOFT_output_limiter extension. Basically adding

Code: Select all

        attribs.Push(ALC_OUTPUT_LIMITER_SOFT);
        attribs.Push(ALC_TRUE /* or ALC_FALSE or ALC_DONT_CARE_SOFT */);

to the context creation attributes during device init when the extension is supported. Might need to update alext.h for the definitions.

[drfrag]

GZDoom 4.4.2 used 1.20.1 and 4.3.3 used 1.19.1. So you mean it's a windows problem and must be addressed in GZDoom itself?

[Graf Zahl]

I added these instructions as described, but how can I test this without endangering my sound hardware? I normally keep the volume slider at 0.25 to match the output I am getting when watching movies so full 1.0 would already kill my system. All I can say that killing monsters on Nuts is extremely loud at a volume setting of 0.01 and due to the low overall settings I use the limiter probably never kicks in.

[Nash]

Gradually spawn in cyberdemons with a console command and simultaneously "kill monsters" them until the volume buildup starts to pile up?

[Rachael]

Windows has a hidden recording device called "Stereo Mix" - when opening the sound control panel you must specifically ask it to show disabled devices. It must also be enabled, afterward. (recap: Sound Control Panel (mmsys.cpl), Show hidden devices, enable Stereo Mix device)

What you can do is leave a recorder running (audacity) using this device, then unplug your speakers, and it should allow you to see what happens (visually) without endangering your sound hardware.

[drfrag]

I'd say just kill yourself surrounded by some monsters and resurrect.