ZDoom

[quote="drfrag"]I did the nuts test and the OpenAL Soft limiter doesn't make any difference with the game master volume at 0.05 in fact it was the same with the old dll.[/quote]
The master volume is multiplied with the per-sound volume, affecting the volume of each individual sound but doesn't influence the overall output limit. So despite the sounds being at 5% its usual volume, the boss sounds or whatever still accumulate up to 100% amplitude (-1...+1 sample values) before the limiter kicks in.

I'd play it safe. Playing the countless copies of same sound at the same time produces loud noise at best and serious damage at worst. It's best to avoid such situations right at the source, like my fix.

I did the nuts test and the OpenAL Soft limiter doesn't make any difference with the game master volume at 0.05 in fact it was the same with the old dll. No harm done but i'm not going to test it with a higher volume (i don't know when the volume limiter kicked in), the sound is strong enough. The later ingame fix definitely works.
LZDoom is also affected and the issue is serious enough, i wonder if it's windows only.

Should be better now. I now apply attenuation to the limit distance as well but also increased the limit to the boss sounds to 4 because that's still safe. This no longer runs a risk of speaker overkill.

Of course they are, but for that case the $limit kicks in and will prevent too many from playing because the monsters are nearby and distance attenuation will also help. But with unattenuated boss sounds none of the mechanisms to keep sound in check will do anything to contain the volume.

I don't think only boss sounds are affected, i notice that when i die and resurrect surrounded by several monsters of the same type the see sounds are played much louder and i don't think i'm imagining things.

I think what it really should do is to ignore the distance for the $limit when playing an unattenuated sound.

[quote="drfrag"]So you mean it's a windows problem and must be addressed in GZDoom itself?[/quote]
It's either a Windows problem or a GZDoom problem, depending on how you look at it. From what it seems, the underlying issue is the game plays the same sound tens or hundreds of times simultaneously. Since sound mixing is additive, this results in the sound playing at a couple tens or hundreds times the normal volume. A limiter reduces the amplitude of sounds around loud peaks, essentially bringing the offending sound back down to 1x normal volume (though other sounds played at the same time are also reduced, so all sounds keep relative volume). Apparently, however, Windows' built-in limiter has a limit, so it won't reduce the 200x or whatever volume of the cyberdemon sounds back to 1x, but still keeps it too high, whereas OpenAL Soft's limiter manages to still keep it in check.

But it could also be argued that perhaps GZDoom shouldn't try playing the same boss death sound (or other local/"full-volume" sound) multiple times at the same time. At least so many of them, anyway. It already prevents pickup sounds from stacking for this reason.

Alternatively, just record what the game is doing while your hardware is turned off, that should also do it.

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

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.

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

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.

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?

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

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] attribs.Push(ALC_OUTPUT_LIMITER_SOFT);
attribs.Push(ALC_TRUE /* or ALC_FALSE or ALC_DONT_CARE_SOFT */);[/code]
to the context creation attributes during device init when the extension is supported. Might need to update alext.h for the definitions.