Echo of the of SSG shot became much quieter.

[AntonieS]

OpenAL Soft 1.23.1, Win7 x64 SP1. Dhewm 3 1.5.3.1305.
Subj compare to 1.5.2.1503. Now it sounds unnatural.

[DanielGibson]

How does it sound compared to 1.4.1?
In 1.5.0 I reduced the volume of all sounds, which (due to some sounds being configured much louder than the can be played, and the max volume being clamped before setting it in OpenAL) changed the relative volume of some sounds, see #326 (comment) for an explanation.

In 1.5.3 that is fixed (I clamp the volume before reducing it), so it should sound like in 1.4.1 and older (incl. orig Doom3 with OpenAL backend) again, except for the bug that was fixed by reducing the sounds in the first place (#179), which is still fixed.

[AntonieS]

1.4.1 is very bad.
1.5.2 sounds much better. But its about echo.
Overall 1.5.3 lesser SSG echo quality but better in other: some ambient sounds, for example announcements that the passage is closed in Admin map, appears only in 1.5.3.

[tyuah8]

In my humble opinion, the code written to reduce the volume of the sounds here:

4567f26

...is both unnecessary and incorrect, because all it does is move the problem to a different volume. Since it multiples the volume by 0.333, all the user has to do is multiple the volume in his config file by 3, or divide by 0.333, in order to counter the changes made and be back at the same problem.

I recommend completely restoring the original game code, which includes removing the clamp, so not just removing the 0.333, so the code will be what it was prior to the following:

3c01757

...and instead, use the following in alsoft.ini:

output-limiter = true

By default, output-limiter is set to false, which causes the situation where too many loud sounds playing causes some of them to go quiet. Setting it to true completely eliminates this issue.

[DanielGibson]

I don't have influence on users alsoft.ini/alsoft.conf

[tyuah8]

Very well, but perhaps you can make your changes optional so users have the option of doing what I just mentioned (using output-limiter = true instead of the hard-coded volume reduction, which seems to be causing other issues).

It is what I opted for with my version of the DOOM 3 engine.

[DanielGibson]

Yeah, that would be an option

[DanielGibson]

## output-limiter:
#  Applies a gain limiter on the final mixed output. This reduces the volume
#  when the output samples would otherwise clamp, avoiding excessive clipping
#  noise.
#output-limiter = true

Are you sure that setting it to true would help?

To me it looks like true is the default, and if anything, then setting it to false might help, at least with the problem I fixed with the initial *= 0.333 fix (lots of loud sounds lowering overall volume and thus making other sounds inaudible, what's described in 3c01757 and #179)

[tyuah8]

Yes it would help. I tested this, and it is counter-intuitive, but false is the default contrary to what the documentation says.

You can test this very easily if you set it to false, and run Dhewm3 with s_volume_dB "10"; you will find that when you fire the shotgun at a wall, the shotgun sound is muffled by the bullets hitting the wall, but the moment you set output-limiter = true, the problem goes away.

---

Your fix actually does not fix the problem, as you apply both the clamp and scale before the s_volume_dB, so all the user has to do to "undo your fix" is increase the volume, which he would have to do anyways, since everything is now quieter; the user would increase by 10 dB, since 10 dB is roughly x3, which counters your 0.333.

Since the clamp to 1 is before both the 0.333 and s_volume_dB, it doesn't actually clamp to 1, but will affect the way the game sounds feel. I believe this right here is what a lot of users are experiencing.

[DanielGibson]

the user would increase by 10 dB, since 10 dB is roughly x3, which counters your 0.333.

that's their problem then, not sure what I should do about it. My goal is for it to sound ok at the default volume, as that's what most people use - and keep in mind that s_volume_dB = 0 is the value you get when turning the slider in doom3's system menu all the way to the right, higher values like 10 are only possible through the console.

Fact is, doom3's audio is inherently buggy, due to some sounds having a way too loud gain configured that only sounds ok-ish due to being clamped to 1.0 (this is the issue I fix by clamping to 1 before scaling down), so whatever I do, it'll be hard to properly fix the issue in a way that always sounds "good" (if Doom3 even ever sounded good in all those edge-cases that cause trouble now) an doesn't depend on OpenAL hopefully handling too many loud sounds that are played at the same time in a way that doesn't sound too bad, or at least behaves similarly to Creative's old OpenAL implementation, or whatever the benchmark is.

(The "proper" way would be editing all sound shaders, basically remixing the game's sound, which I don't really want to do, and I'm not qualified for anyway)

[tyuah8]

Well, it is your repo, so you decide what you would like to do, but what I am doing for my DOOM 3 is the following:

• use output-limiter = true, which fixes the sound muffling issue without any source code change
• manually edit every single sound volume that I personally feel is either too quiet or too loud, and I am doing this by modifying the .map file and/or the .sndshd file

Both points are changes outside the engine source code, as I do not consider either to be engine bugs; they are either configuration bugs with OpenAL or map bugs by the developers.

[DanielGibson]

I'll look into it..

by the way, what project is "your Doom3"? :)

[tyuah8]

I have the source code locally, but I original forked from TTimo 12 years ago to work on something widescreen related. I recently went back to working on DOOM 3 with new changes to both the engine and the pk4 files.

One of the changes you made that I really liked was the fixes to OpenAL and 296 which I copied over and adapted to my source code. I gave you credit by referencing the Pull Request and or commits involved.

So... excellent work to you!

[DanielGibson]

Your suggestions (together with a menu that allows configuring this and even OpenALs output-limiter) is implemented in https://github.com/DanielGibson/dhewm3/tree/imgui-rebased

Can't say that I heard much of a difference with the double shotgun though

[j4reporting]

#output-limiter = true

To me it looks like true is the default,

It sure looks like this, but the debug log suggest this is not the case.

[ALSOFT] (II) Key output-limiter not found
[ALSOFT] (II) Output limiter disabled

This may be a bug, because the included openal-config program also assumes that the output-limiter (Gain Limiter) is enabled by default.
The GUI (at least the Windows version) does not write the output-limiter=true line in the %APPDATA%\alsoft.ini file. Only if disabled then the line output-limiter will be set to false in the alsoft.ini file.

You can also override the output-limiter setting in a local alsoft.ini file placed in the dhewm3 directory.
It will only override the settings included in the game's alsoft.ini file.

i.e. ( had some settings configured in %APPDATA% )

[General]
stereo-mode=headphones
default-hrtf=Built-In HRTF
excludefx="eaxreverb,reverb"

here's the openal debug log (trimmed down)

[ALSOFT] (II) Initializing library v1.23.1-d3875f33 master
[ALSOFT] (II) Supported backends: wasapi, dsound, winmm, null, wave
[ALSOFT] (II) Loading config C:\Users\<username>\AppData\Roaming\alsoft.ini...
[ALSOFT] (II)  found 'stereo-mode' = 'headphones'
[ALSOFT] (II)  found 'default-hrtf' = 'Built-In HRTF'
[ALSOFT] (II)  found 'excludefx' = 'eaxreverb,reverb'
[ALSOFT] (II) Got binary: c:\Games\dhewm3-pre, dhewm3.exe
[ALSOFT] (II) Loading config c:\Games\dhewm3-pre\alsoft.ini...
[ALSOFT] (II)  found 'output-limiter' = 'true'
....
[ALSOFT] (II) Found excludefx = "eaxreverb,reverb"
[ALSOFT] (II) Key default-reverb not found
[ALSOFT] (II) Key eax/enable not found
[ALSOFT] (II) EAX disabled because EAXReverb is disabled.
...
[ALSOFT] (II) Found stereo-mode = "headphones"
[ALSOFT] (II) Found default-hrtf = "Built-In HRTF"
[ALSOFT] (II) Loading !1_Built-In HRTF...
....
[ALSOFT] (II) Found output-limiter = "true"
[ALSOFT] (II) Output limiter enabled, 0.0000dB limit

Can't say that I heard much of a difference with the double shotgun though

The best way to hear it is to take 1-2 steps back from the wall.

[DanielGibson]

In the branch I linked above you can enable and disable the output limiter in dhewm3, with a cvar or by clicking in the new settings menu.

It indeed seems to be disabled by default.

[j4reporting]

yeah, I just tried to compile the branch with VStudio 2022 but I get these errors:

1>Dhewm3SettingsMenu.cpp
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\cstdio(82,25): error C2039: 'use_idStr_snPrintf': is not a member of '`global namespace''
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\cstdio(82,13): error C2873: 'use_idStr_snPrintf': symbol cannot be used in a using-declaration
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\cstdio(83,25): error C2039: 'use_idStr_vsnPrintf': is not a member of '`global namespace''
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\cstdio(83,13): error C2873: 'use_idStr_vsnPrintf': symbol cannot be used in a using-declaration
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\cstring(32,25): error C2885: 'idStr::Cmp': not a valid using-declaration at non-class scope
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\cstring(39,25): error C2039: 'use_idStr_Cmpn': is not a member of '`global namespace''
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\cstring(39,13): error C2873: 'use_idStr_Cmpn': symbol cannot be used in a using-declaration

[DanielGibson]

Try again, I just pushed a fix for that :)

[j4reporting]

thanks. One thing that I encountered.
project compiles and links successfully using an older version of cmake ( 3.26.4 )

newer cmake versions set the link flag /SAGESEH. I tried with cmake 3.29.3
this fails to link the dhwem3 binary.

link errors:

3>libz.a(compress.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(inflate.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(crc32.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(deflate.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(zutil.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(adler32.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(inftrees.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(inffast.o) : error LNK2026: module unsafe for SAFESEH image.
3>libz.a(trees.o) : error LNK2026: module unsafe for SAFESEH image.

I use the old libs dhewm3-libs\i686-w64-mingw32 .

[DanielGibson]

why does it use libz.a, shouldn't it use zlib1.lib?

[j4reporting]

good catch. /SAFESEH was always enabled, but
it seems the cmake FindZLIB.cmake module has changed
not sure what enabled the search for static libs.

CMAKE 3.26.4
-- Found ZLIB: C:/Users/XXXX/source/repos/dhewm3-libs/i686-w64-mingw32/lib/libz.dll.a (found version "1.2.7")

CMAKE 3.29.3
-- Found ZLIB: C:/Users/XXXX/source/repos/dhewm3-libs/i686-w64-mingw32/lib/libz.a (found version "1.2.7")

UPDATE:
I renamed libz.a to _libz.a and now cmake 3.29.3 uses libz.dll.a

UPDATE 2:
restored libz.a and tried cmake 3.28.5
Could be a cmake 3.29.x issue. cmake 3.28.5 uses the same FindZLIB.cmake module as 3.39.x but finds libz.dll.a instead of libz.a
Not sure how to look into this. I got a trace with --trace-expand but it's quite a lot of output.

[DanielGibson]

nevermind, I just pushed a commit that removes zlib and uses integrated miniz instead

[j4reporting]

regarding the openal config GUI utility. The checkbox for 'Gain Limiter' has 3 options! Default, enabled and disabled.
The problem here is that on Windows you can't see any difference between default and enabled state!

on Linux the 'default' option is unchecked and has a dark grey color.

[DanielGibson]

You should report that to OpenAL Soft, I'm not involved with that project :)

In dhewm3 the three states should be easy enough to tell apart

[DanielGibson]

Here's a current build for Windows:
dhewm3-1.5.4pre-imgui3_win32.zip

[j4reporting]

yeah no issues with the output-limiter setting in imgui.

One point regarding the imgui, though.
On first start of the imgui the window should be resized to something more sane than
Size=32,72

the default size is ignored

here is my imgui.ini after opening and closing the imgui for first time:

[Window][Debug##Default]
Pos=60,60
Size=400,400

[Window][dhewm3 Settings]
Pos=60,60
Size=32,72

UPDATE: ignore this, I missed the new commits