Strange audio filtering sound FX

[TafferKing451]

I was comparing vanilla Doom 3 and Dhewm3 with some dev friends and we noticed that the audio effects for Dhewm3 have some filtering going on that I'm not sure are intended. It sounds a bit like a lowpass/reverb being applied? I captured me firing the machine gun in both the vanilla Steam version and the source port here to make it clearer. Perhaps I have some odd option or config setting enabled? https://www.youtube.com/watch?v=QFLoM-EL0-Q

Note that I have EAX disabled in both versions.

Thanks for your time, and working on the port!

[DanielGibson]

Can you try if using openal in vanilla doom3 (but without EAX) sounds more like dhewm3? you can copy over the openal32.dll from (latest) dhewm3 and otherwise follow https://github.com/dhewm/dhewm3/issues/326#issuecomment-1366332272

EDIT: oh, and just to be sure, it might make sense to compare the sound at the exact same place - maybe even a testlevel (like map test/test_box in the console, then give all to get all weapons)

One difference in sound of course is that with dhewm3 the machinegun doesn't "stutter" anymore, but plays at a steady rate like it's supposed to (the problem as that original doom3 only played sounds about every 100ms, but not even exactly 100ms but like some nearest multiple of 16ms or sth.. either way, that could delay a sound being played by about 100ms, but if you were "lucky" it played almost immediately, causing that stuttering/drifting).

Another problem was that clipping happened when lots of loud sounds were playing (esp. when shooting a nearby metal wall with the shotgun), or with openal-soft that somehow cause the overall volume to decrease. I fixed that by reducing the volume of all sounds so they're less close to full volume and mixing them is less likely to clip that much (my first attempt at that also caused problems because turned out some of the Doom3 "sound shaders" had a way too high volume set that only sounded correctly because they were all clamped to a gain of 1.0).. anyway, could be that the missing clipping makes it sound different? Just a wild guess, no idea

[DanielGibson]

Here's a current Win32 build of dhewm3: dhewm3-1.5.3pre-soundfixes.zip

it doesn't include any experimental 144Hz code, but it does include the latest sound fixes (it's the current state of the git master branch) and the latest openal-soft release (1.22.2)

[TafferKing451]

I have some more footage here. This is broken into 3 parts: vanilla doom 3 (no OpenAL), vanilla doom 3 (with dhewm3's OpenAL library) and dhewm3. I recorded each scenario in the test box scene, and left open the console at start to confirm which library/version was loaded: https://www.youtube.com/watch?v=KxdVi5Vl51Q

The results I'm seeing suggest that OpenAL does seem to change the audio presentation of the original game. The Dhewm3 mix/volume does seem a little different than Doom 3 with OpenAL, but I could see that being the code to prevent the sound clipping as you noted.

EDIT: This was recorded on the above version of dhewm3, not the version I have with experimental 144hz tweaks.

[DanielGibson]

The Dhewm3 mix/volume does seem a little different than Doom 3 with OpenAL, but I could see that being the code to prevent the sound clipping as you noted.

Yep, if you increase the system volume accordingly it should (hopefully) sound (pretty much) the same?

I agree that even in Doom3 1.3.1 OpenAL sounds kinda different than the classic software sound backend, trying to figure out what exactly the difference is, though. Possibly with OpenAL on 1.3.1 the impact sounds (those higher "cling" sounds when the bullet hits the metal wall) are more dominant, while with the classic backend you hear more of the shots from the weapon itself? My impression is that with dhewm3 the impacts are a bit less dominant though.

Might be worth a try to test when standing directly in front of a wall, in case distance falloff of the sound volume is different somehow?

(Part of the problem here is that, apart from my miserable memory, most of the OpenAL changes that dhewm3 did compared to orig Doom3 were done by @dhewg before I got involved in the project, so I'm not sure if there were many changes that could make it sound different from 1.3.1, apart from my "make it less loud" hack. And of course all that was 11 years ago, so likely dhewg has forgotten the details as well)

[TafferKing451]

I don't think it's limited to weapons/impacts. It seems to apply the effect to every audio FX. You can notice it on the footsteps here: https://www.youtube.com/watch?v=aYfvT9GLKsk

My guess is that the OpenAL library was configured to apply some sort of filter to all spatialized sounds, regardless of whether EAX was enabled.

[DanielGibson]

I just checked the code, and I'm pretty sure that if s_useEAXReverb is disabled (0) when starting the engine - and thus idSoundSystemLocal::useEFXReverb is false - no OpenAL effects or filters are applied.

So I guess that the differences are likely related to mixing and the volume, like how (loud) sounds at the listener position are mixed in, and maybe how much clipping happens. I hope I'm not bullshitting here (I'm no expert on audio), but my understanding is that clipping doesn't have to sound bad and can give the sound more punch - I mean, the whole electric guitar overdrive/distortion thing is just clipping. So could be that

1. The software backend has more pronounced clipping than OpenAL (or at least OpenAL Soft) in general
2. My hack that prevents clipping makes it sound thinner - though even without it, it seemed like OpenAL Soft prevented clipping by reducing the overall volume

How does the software mixer sound change if you reduce the "global" volume (in the Doom3 Options -> System)? At least when using OpenAL it would reduce the volume of each sound before mixing and thus prevent/reduce clipping, could be it's the same with the old software backend

[TafferKing451]

As per my hunch, I tried grabbing a different Doom 3 OpenAL library (from here: https://github.com/bibendovsky/eaxefx) and swapping it into Dhewm3 and indeed - the filtering is gone. The sounds, aside from the volume adjustments, are unfiltered in the same way as Doom 3 vanilla without OpenAL. Here's a comparison on the same version of Dhewm3, the first half using the current Dhewm3 OpenAL library, and the second half using the above eaxefx OpenAL library: https://www.youtube.com/watch?v=2XVc0hb4Ouk

However, I imagine the Dhewm3 OpenAL library probably has specific settings for platform compatibility, so it's not a full fix. It is, however, a notable discovery for where the issue is happening.

[DanielGibson]

WTF O_O

Good find!

The "dhewm3 OpenAL library" is just vanilla OpenAL Soft 1.22.2 (or some older version in the 144hz dhewm3 build you originally tested), and my understanding is that eaxefx is also based on OpenAL Soft (and adds EAX compatibility, which dhewm3 doesn't use because the Doom3 EAX code is ported to EFX in dhewm3, but you disabled that anyway).

@bibendovsky @kcat Do you have any idea why vanilla openal-soft 1.22.2 vs the eaxefx OpenAL32.dll would sound different with dhewm3? See (or rather hear) the video in the previous comment

[kcat]

Perhaps it's HRTF? With HRTF, sounds are filtered to make it seem like it comes from an external point around you, creating a binaural mix that's better for headphones than basic stereo. When the device is configured in the system as headphones, OpenAL Soft tries to use HRTF by default. The OpenAL Soft binary releases have a built-in HRTF profile so it can use HRTF without anything more, but if the eaxefx build excludes the built-in HRTF profile, then when it tries to use HRTF it'll fail if external HRTF profiles aren't available and fall back to basic stereo.

There are ways HRTF can be disabled if you want. In the dhewm3 code, the ALC_SOFT_HRTF extension can be used toggle HRTF on or off, or let it act as default (I would only suggest using this if you add an on/off/default option the user can change, to avoid forcing specific behavior users).

Alternatively, you use the alsoft-config utility to force it off for all apps using OpenAL Soft (or if you use File->Save As... instead of clicking Apply, save the config to the same folder as the executable to have the settings effect only that executable). Or instead of using alsoft-config, you can manually create an alsoft.ini file (on Windows, or alsoft.conf elsewhere) in the same folder as the executable, and add the lines:

[general]
hrtf = off

to force it off for the game.

[DanielGibson]

Thanks, that sounds plausible!

@ForbiddenDonut99 can you try running it with an alsoft.ini (as @kcat described) with hrtf on and off and see if one setting sounds right?

[TafferKing451]

I created the config file aisoft.ini with the above lines and placed it in the same directory as the executable. I swapped back to the OpenAL32.dll that Dhewm uses. I'm including a screenshot here to ensure I did the correct procedure: https://i.imgur.com/zwCUEVR.png

The video result below suggests the filter effect is still present with Dhewm's version of OpenAL, regardless of the config's presence. I'm comparing it to the @bibendovsky OpenAL version (first half is Dhewm OpenAL, second half is EAXEFX): https://www.youtube.com/watch?v=j0ygMUa8cJE

Let me know if I messed up placing the configuration!

[DanielGibson]

aLsoft.ini, right?

[dhewg]

most of the OpenAL changes that dhewm3 did compared to orig Doom3 were done by @dhewg before I got involved in the project

It's been so long, I don't remember all the details too... But in general I tried to port stuff and keep at as close to the original as possible. But in doubt it's all in the git history.

Unrelated to dhewm, note that I recently stumbled upon random DSOAL packages, which not only shipped windows binaries, but also a ini which was set up for HRTF headphone usage, exactly like @kcat describes.

[kcat]

Assuming the config file was named correctly, a trace log of the two DLLs would be helpful also. Set the ALSOFT_LOGLEVEL environment variable to 3, and then either capture what's written to stderr or set ALSOFT_LOGFILE to a full path+filename to have it written to the specified file.

[TafferKing451]

Yeah, sorry - the file is named correctly. I just typo'd in the github reply.

@kcat Can those commands also go into the alsoft.ini configuration file?

[DanielGibson]

Can those commands also go into the alsoft.ini configuration file?

No. The easiest way should be to create a startdhewm3.bat file (in the same directory dhewm3.exe is in), like

SET ALSOFT_LOGLEVEL=3
SET ALSOFT_LOGFILE="C:\whatever\oallog.txt"
dhewm3.exe

and then double-click that .bat file to start dhewm3 instead of starting the .exe directly

[DanielGibson]

@ForbiddenDonut99 have you gotten around to trying this yet? :)

[adecrepitcabbage]

@ForbiddenDonut99 If you're willing to stop by and explain what you meant by using the OpenAL to fix the issue, I would be eternally grateful. All I've wanted to do is play the original game on a modern system with alt-tabbing, nothing changed; there is currently a fix for the sound levels, but it changes many of the sfx, adding the BFG sound choices, making the experience feel significantly worse to my ears.

Now, @DanielGibson - hopefully some of this will help you.

In addition what was mentioned in #502 it's worthy of note that the sound effect levels can also effect faintly - reverb might be the wrong word to use, distant? Echoed? Regardless, it requires turning the volume up significantly to hear effects that were properly balanced in the original game, without a corresponding way to lower effects that are not muffled. Naturally, this isn't the best outcome for the old ears. :P

I notice you have a potential solution. Would you mind if I tried to apply it and reported back to you?

I am NOT technically adept. I actually hate technology with a fiery passion; a real luddite. xD So I might need some assistance applying it; my only virtue is I have several installations of Dhewm, and several installations of Doom 3, because I do not trust any operation to be foolproof, and certainly not any to be me-proof.

Let me run over the process with you.

create a file, statdhewm3.batch edit the file; add the following: SET ALSOFT_LOGLEVEL=3 SET ALSOFT_LOGFILE="C:\whatever\oallog.txt" dhewm3.exe

I do NOT need to create aisoft.ini to attempt the following fix, correct?
If so, I will try this the moment I get back from work. c:

[DanielGibson]

Let me run over the process with you. (...)

this is basically correct, but keep in mind that it must be in different lines, like I posted (and you should adjust C:\whatever\oallog.txt to a directory that exists where the log can be written)

You do not (should not) need an alsoft.ini (it's aLsoft, this is about OpenAL, not OpenAI which is something entirely different)

However the goal of this is to do this twice: Once with the openal32.dll that is bundled with the build linked above, and then (after copying the resulting oallog.txt) again with the openal32.dll from https://github.com/bibendovsky/eaxefx/, specifically from https://github.com/bibendovsky/eaxefx/releases/download/v1.0.9-1/eaxefx_bin_win32_v1_0_9.zip

Then post both copies of oallog.txt here so we can compare them and hopefully see what's different in the two OpenAL implementations (that are actually based on each other!).

Probably makes sense to check if both OpenAL versions actually do sound different on your system, in case it's something that's somehow specific to @ForbiddenDonut99's system.

[adecrepitcabbage]

@DanielGibson Ah, lovely, thank you.

For the record, I am incredibly grateful for the work you do; it's easy to imagine a future where Doom 3 is unrunnable within a few years, given the awful state of backwards compatibility and the lack of interest in preserving things, as well as how much is closed source. I simply find myself feeling glum a lot, over things that probably don't matter at all.

Regardless, a text log (or two) is something I can do without worrying about copying down to lossy formats. I will also include details on the sound quality on this system too, so that ideally ForbiddenDonut and I aren't outliers... Or if we are, at least we did due diligence. ;)

I will attempt to have that to you by the night of today, tuesday the 31st, on PST time. There is no rush on interpreting the provided data; I just want to do something, since it's an issue that matters to me.

[DanielGibson]

Great, thanks for doing this, and there's no rush to provide that data either, unlikely I'll get to it before the weekend :)

(though TBH, kcat probably has a much better chance at figuring out what's wrong based on the logs than I do)

[DanielGibson]

Ok turns out the .bat must look slightly different for this to work..

SET ALSOFT_LOGLEVEL=3
SET ALSOFT_LOGFILE=oallog.txt
dhewm3.exe

no quotes around the filename, and using just a filename works, the log is then written in the dir dhewm3.exe is in

Furthermore, using that eaxefx OpenAL32.dll doesn't work quite as I thought: It's not a full OpenAL implementation, but some kind of wrapper that needs a real implementation. Specifically: To use the eaxefx OpenAL32.dll, rename the OpenAL32.dll that comes with dhewm3 to "soft_oal.dll" and then copy the OpenAL32.dll from https://github.com/bibendovsky/eaxefx/releases/download/v1.0.9-1/eaxefx_bin_win32_v1_0_9.zip into the dhewm3 dir.

Anyway, on my machine I couldn't hear any difference between the two, so it would be nice if @ForbiddenDonut99 (or @adecrepitcabbage if they can reproduce the issue) could run this and post the oallog.txt from both runs (with orig OpenAL32.dll and the one from eaxefx).

However, I have a theory: As apparently that eaxefx OpenAL32.dll uses another available openal implementation under the hood, is it possible that in @ForbiddenDonut99's case it used one installed systemwide, which was not OpenAL-Soft? This should be visible when scrolling up in the console, or by looking at My Documents\dhewm3\dhewm3log.txt

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'OpenAL Soft on Headphones (High Definition Audio Device)'
OpenAL: found device 'OpenAL Soft on 5 - M27Q X (AMD High Definition Audio Device)'
OpenAL: found device 'OpenAL Soft on Digital Audio (S/PDIF) (High Definition Audio Device)'
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.22.2
OpenAL: found extensions for resetting disconnected devices
OpenAL: found EFX extension
OpenAL: found 256 hardware voices

(that would show a different OpenAL renderer if openal-soft isn't used)

[DanielGibson]

Oh, and eaxefx also creates a eaxefx_log.txt that contains information about the openal implementation it uses

[adecrepitcabbage]

@DanielGibson

Hey, sorry I didn't get to it over the week + weekend; managed to do something to my gut, seems to be getting better now, thankfully. The pastes are set to last for a month, so don't worry about getting to them by any time; I've kept the logs on hand, just in case it takes longer, too. I do have a very weird report for you, though. Not so much the logs, I think, but...

Here is for the eaxefx_log; What's weird is that subbing this out (using your modified instructions) completely nuked the sound in dhewm. Dhewm nukem'd it, you might say. All of it. I've got nothing. (Also, I've noticed that the intro doesn't play and needs to be skipped, and that the video memory options don't stay remembered on subesquent loads e.g. it always defaults to 64 MB; could I be missing some other installation-based problem?)

Here are the pre-soundfix logs (oallog); maybe you'll see something I don't. Oh, and the sound worked with the pre-soundfix .dll. I compared and contrasted with my default DOOM3 'control' file, and the sound was better - I didn't need to ram up the volume to hear things and then get my ears blown out by some loud sfx, nor did I miss all the ambient sfx - but still has a faintness to it. If the problem persists I probably need to look into recording software. I'll mull that over, in the meantime...

Just for the record, here's my audio config in dhewm3.log, too:

Setup OpenAL device and context
OpenAL: found device 'OpenAL Soft on Speakers (3- High Definition Audio Device)'
OpenAL: found device 'OpenAL Soft on BenQ GW2480 (High Definition Audio Device)'
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.22.2
OpenAL: found extensions for resetting disconnected devices
OpenAL: found EFX extension
OpenAL: found 256 hardware voices

[bibendovsky]

What's weird is that subbing this out (using your modified instructions) completely nuked the sound in dhewm. Dhewm nukem'd it, you might say. All of it. I've got nothing. (Also, I've noticed that the intro doesn't play and needs to be skipped, and that the video memory options don't stay remembered on subesquent loads e.g. it always defaults to 64 MB; could I be missing some other installation-based problem?)

EAXEFX tries to load an OpenAL implementation library named as eaxefx_driver.dll, dsoal-aldrv.dll or soft_oal.dll. This implementation file could be placed along with main executable or any other directory specified in the environment variable PATH.

[DanielGibson]

Here is for the eaxefx_log;

this looks like you forgot to rename the original OpenAL32.dll (that comes with dhewm3) to soft_oal.dll (eaxefx tries to open that file and fails)

[adecrepitcabbage]

EAXEFX tries to load an OpenAL implementation library named as eaxefx_driver.dll, dsoal-aldrv.dll or soft_oal.dll. This implementation file could be placed along with main executable or any other directory specified in the environment variable PATH.

this looks like you forgot to rename the original OpenAL32.dll (that comes with dhewm3) to soft_oal.dll (eaxefx tries to open that file and fails)

Oh, I remembered to rename it, all right... to sof_oal.dll, left off the t apparently. Feel like a right moron.
Gimme a second, I can actually give you a proper comparison...

Here is the PROPER eafex_log. Seriously, how embarrassing...

From a sound perspective, everything was very quiet and muted unless right on top of a sound source. Since the clearest sound came from the presoundfix file, I'm feeling increasingly gloomy that mine just be my machine and configuration, and not a Dhewm issue; even still, thanks for walking me through this and I hope it's useful, somehow.

[DanielGibson]

Hmm at this point I really would have expected the the OpenAL32.dll that comes with dhewm3 and the eaxefx one to sound the same (when the latter uses the former renamed to soft_oal.dll)

Anyway, do you also have the oallog.txt from the run using eaxefx?

[adecrepitcabbage]

Right here; don't sweat it too much, I feel like I need to be able to at least record samples for comparison, I realise that talking about sound difference doesn't help narrow things down. Here's the other oallog!

[bibendovsky]

Fixed error "Null AL source." in the wrapper.