[EAX] Hitman 2 SA (v1.01) muffled gunshots

[Kappa971]

Hi @kcat, as described here: kcat/dsoal#51
The sound of the gunshots becomes very muffled, when you turn and move away from the enemies.
Here the log files:
alsoft_log.txt
dsoal_log.txt

@Phantom-Aspekt uploaded this video which perfectly reflects the problem: https://youtu.be/Mwk1VWPuXc4

[Kappa971]

I think I've found the culprit: by turning off the chorus effect in OpenAL Soft, the gunshot sound works fine.
What does the chorus effect do? Is it a big loss if deactivated?

EDIT
Without chorus, the sound of footsteps is louder, it seems as if the chorus effect is muffling some sounds according to the distance (incorrectly). It also seems to be the culprit of the exaggerated reverb in GTA 3, as described here: #706 (comment)

EDIT2
The chorus effect is actually messing with the reverb. Disabling it also causes the inability to use EAX in some games (this happened to me with Serious Sam The First Encounter), and it disables reverb in others (??).

[kcat]

The chorus effect creates pitch-shifted "echoes" that are panned to the left and right. It's typically used for music, and the general idea is to take a single music source and create a fuller and more volumetric sound (e.g. the difference between a single instrument and an ensemble of that instrument, or a person singing and a chorus singing, hence the name).

Disabling chorus probably breaks EAX support, since EAX has chorus running by default on the second effect slot (not sure why since it couldn't be controlled in EAX1/2/3, although I know Sound Blaster cards as far back as the AWE32 had reverb and chorus effect options for MIDI playback; maybe a quirk of the older hardware EAX started with).

I don't know why having chorus on would cause this bug, though. The effects are additive, so whatever chorus does is added on top of reverb and the normal/dry sound. Having chorus on shouldn't cause the dry sound to go silent or become heavily filtered.

[Kappa971]

I don't know why having chorus on would cause this bug, though. The effects are additive, so whatever chorus does is added on top of reverb and the normal/dry sound. Having chorus on shouldn't cause the dry sound to go silent or become heavily filtered.

Unfortunately this is what is happening, maybe there is a bug somewhere in the chorus effect?
It would appear (but I haven't personally tested it) that the Hitman 2 demo is working fine. This would suggest a bug in the game in the final version, but with ALchemy it works well...

The other weird thing is that the chorus is also affecting the reverb... If I disable the chorus, the reverb seems to turn off but it could be a bug of games not detecting the chorus effect (for example some games without chorus effect do not allow EAX to be enabled at all).

However, the bug seems limited to the chorus effect even though it probably doesn't help much 😅

[bibendovsky]

Disabling chorus probably breaks EAX support, since EAX has chorus running by default on the second effect slot (not sure why since it couldn't be controlled in EAX1/2/3, although I know Sound Blaster cards as far back as the AWE32 had reverb and chorus effect options for MIDI playback; maybe a quirk of the older hardware EAX started with).

Even the chorus is initially loaded into the second FX slot it should not be used in processing by default, since initial active FX slot settings on a source enables only the first FX slot (or a primary FX slot in EAX5 which effectively is the first one by default).

[Kappa971]

I await further developments, I'm available to test and close this issue 🙂

[Kappa971]

It probably won't help in resolving this problem, but this bug in Hitman 2 is also present with the DSOAL build prior to the new EAX extensions of OpenAL Soft (https://github.com/kcat/dsoal/tree/e7a82d4fda8502eef9f8aacaa207199917d94167) with the latest build of OpenAL Soft. In this case, however, disabling the chorus effect has no change (maybe it's using a chorus effect built into DSOAL in this old build?).

[kcat]

I think chorus is just a red-herring. It can't even be used prior to EAX4, there's nothing with it that can affect the dry path or reverb path, and disabling it breaks EAX in unexpected ways causing unknown behavior.

What stumps me is that it seems to work fine for some people, meaning it's not something like an incorrect algorithm or an incorrect conversion from DSound to OpenAL. And being that OpenAL Soft's code is largely system-agnostic, it's not some hardware difference. It's more subtle, more like an improperly initialized (or uninitialized) variable that's sometimes the wrong value. Though even in that case, I'd expect the issue to be more intermittent, not consistently bad for one person and consistently good for another.

[Kappa971]

I think chorus is just a red-herring. It can't even be used prior to EAX4, there's nothing with it that can affect the dry path or reverb path, and disabling it breaks EAX in unexpected ways causing unknown behavior.

This make sense.

What stumps me is that it seems to work fine for some people, meaning it's not something like an incorrect algorithm or an incorrect conversion from DSound to OpenAL. And being that OpenAL Soft's code is largely system-agnostic, it's not some hardware difference. It's more subtle, more like an improperly initialized (or uninitialized) variable that's sometimes the wrong value. Though even in that case, I'd expect the issue to be more intermittent, not consistently bad for one person and consistently good for another.

In this case no, I'm the second person who notices this bug with this game. I think this can be reproduced by everyone (unless using headphones with HRTF produces a different result, but I have no headphones to try with).

[Kappa971]

This issue is also present with OpenAL Soft 1.20 and an old build of DSOAL from October 2020, so we can at least say that Hitman 2 never worked well with DSOAL. Could it be a problem like Max Payne? Not the same obviously but maybe the game is giving invalid values which somehow ALchemy and the old Creative drivers accepted while with DSOAL it is causing weird behavior, but this is just a guess with no basis...

Anyway I noticed that the last commit makes sure that when you deactivate the chorus effect, EAX is deactivated. I will change the title since we have ascertained that the chorus effect has nothing to do with the bug encountered.

EDIT
Anyway which of the effects could be the culprit of causing muffled audio in distant gunshots?
As further information, the game uses EAX 3. Information taken from Wikipedia:

[kcat]

Anyway which of the effects could be the culprit of causing muffled audio in distant gunshots?

If it's EAX related (that is, EAX parameters are the cause, not just having EAX enabled in the game is causing it), the issue would likely be with the occlusion/obstruction and filter properties since those apply high-frequency attenuation to sources. I'm not seeing anything wrong with them, though. The context's air absorption property had an issue in the 1.22.0 release, but that's been fixed in Git.

[Kappa971]

I can confirm that with ALchemy and X-Fi there is no such bug, and if the problem is not OpenAL Soft, maybe it is DSOAL? (even older versions of DSOAL have this bug with this game).
I also noticed that the volume of the sound effects is different than the X-Fi (on the X-Fi the sounds are louder)... for example the sound of this door opening (first mission):

in DSOAL it is inaudible, the volume is too low. Maybe the same thing is happening with gunshots?

[kcat]

I also noticed that the volume of the sound effects is different than the X-Fi (on the X-Fi the sounds are louder)... for example the sound of this door opening (first mission):
...
in DSOAL it is inaudible, the volume is too low. Maybe the same thing is happening with gunshots?

Perhaps, if the door sound is a 3D/world sound like gunshots, it may be triggering the same issue as the gunshot sounds.

[ThreeDeeJay]

I just tested the full game (v1.01) with the current latest kcat/dsoal@0e8792c and OpenAL Soft seems to be the culprit variable: 1.22.0 was the last (stable) build that worked.
✅OpenAL Soft 1.21.1
✅OpenAL Soft 1.22.0
❌OpenAL Soft 1.22.1 - Upgrading eax.dll to v4.0.1.0 makes no difference
❌OpenAL Soft 1.23.0
Hitman 2 Silent Assassin DSOAL log+files.zip
Can anyone else replicate these results on their end?

If there was an easy way to get every git DLL between 1.22.0 and 1.22.1, I could track down the exact commit that caused the issue, but I'm not sure if that's available anywhere since artifacts from 1.22.1 and older are already expired on Github and Appveyor. Perhaps there's some github actions voodoo I don't know about 🤔

Check out #714 (comment)

[kcat]

Are you able to try the latest Git version of OpenAL Soft? There has been some work to improving EAX compatibility with it over 1.23.0.

[ThreeDeeJay]

Well, I'll be damned. The 1.23.0-9fd9fee3 build I used was just from a couple weeks ago so I didn't think it'd be fixed since then but sure enough, as luck would have it, seems fixed as of ac01cbf 👏
https://youtu.be/ytaJznB2tpw
1.23.0-ac01cbf-EAX.dllV4.zip

[ThreeDeeJay]

On a side note, @kcat do you know if there's any benefit in upgrading eax.dll (EAX Unified)?
I've noticed that using v4.0.1.0 makes EAX 3.0 and lower games query EAX 4 support in both the DSOAL and ALchemy logs (these are from Prince of Persia: The Two Thrones), though it never gets used which isn't surprising, but I wonder if certain versions (or even the presence) of EAX Unified is known to cause issues🤔

[kcat]

On a side note, @kcat do you know if there's any benefit in upgrading eax.dll (EAX Unified)?

I don't know. Honestly, I'm surprised a DLL like that (closed/propriety, provided with the games that use it) is upgradable. I'd expect ABI breaks, at least on occasion, to handle new features and functionality since it isn't intended to be perpetually upgradable like OpenAL/OpenGL/etc. Updates to the DLL would be controlled by the developer to ensure a compatible version (or they could rebuild the executable for an updated API/ABI). Though I'm not too familiar with eax.dll to know the ins and outs of it, maybe Creative did design it with a stable ABI.

Presuming there is ABI compatibility, upgrading the DLL can fix bugs, improve performance, or provide other benefits. Though software isn't perfect, so if the game relies on the specific behavior of a particular version of the DLL, or if a newer version of the DLL introduces a bug in something the game uses, it can create new problems. It would have to be tested on a case-by-case basis.

[ThreeDeeJay]

Fair enough. I guess I'll just stick with just upgrading within the same major version number to check if it fixes known bugs to minimize/avoid the unnecessary risks. 👌

[Kappa971]

I compiled the latest OpenAL Soft and DSOAL builds and the problem is not solved. I don't have headphones, I tried with stereo speakers.
These are the settings of OpenAL Soft (for safety I disabled CMSS-3D and set OpenAL Soft to "stereo"):

[General]
sample-type=float32
channels=stereo
frequency=48000
stereo-mode=speakers
drivers="wasapi,"

[decoder]
hq-mode=true

DSOAL + OpenALSoft:
Hitman 2 Silent Assassin 2023.03.27 - 16.46.27.02.zip

X-Fi TiHD ALchemy + Creative OpenAL + CMSS-3D:
Hitman 2 Silent Assassin 2023.03.27 - 16.53.00.03.zip

[kcat]

I compiled the latest OpenAL Soft and DSOAL builds and the problem is not solved.

Double-check that dsoal-aldrv.dll was updated with the latest DLL. Can you provide logs using the latest OpenAL Soft and DSOAL builds?

[ThreeDeeJay]

D*ng it, my bad, @Kappa971 is right. I jumped the gun here.
EAX must've gotten disabled at some point for some reason, so DSOAL HRTF was active but the bug didn't happen since only EAX On is affected.
Also, turns out something similar happened in 1.22.0 and earlier: EAX was "Enabled" in the settings, but actually greyed out so it wasn't active either, so no bug.

Sorry for the false alarm everyone, looks like we're back to square one 😅

[Kappa971]

I compiled the latest OpenAL Soft and DSOAL builds and the problem is not solved.

Double-check that dsoal-aldrv.dll was updated with the latest DLL. Can you provide logs using the latest OpenAL Soft and DSOAL builds?

alsoft_log.txt
dsoal_log.txt

[mirh]

(or even the presence)

Please, forget my misplaced blame/hope.
In a very very narrow sense with blinkers, it's not even technically wrong to say that it's only with unified that games break.
But it's not really its fault (and I'm not sure what you could miss without it altogether?) and it's not like COM loading couldn't bite you even in other cases anyway.

since it isn't intended to be perpetually upgradable like OpenAL/OpenGL/etc.

All versions before 4.0.1.0 (if not even that, who knows what may have gotten lost from creative's developer ftp server) had a redist that updated the system-wide dll in the system32 folder. Of course its entire purpose seems kind of that.

[Kappa971]

Is this problem still present with the latest versions of OpenAL Soft? If so, any ideas on how to resolve this strange dilemma before all the Sound Blaster cards die? 😅

[Mrblubb]

@Kappa971 @ThreeDeeJay So I assume the problem still persists with this game and that the Airtable configuration for it is irrelevant ?

[ThreeDeeJay]

Is this problem still present with the latest versions of OpenAL Soft? If so, any ideas on how to resolve this strange dilemma before all the Sound Blaster cards die? 😅

Sadly, yes, as of the latest build: https://youtu.be/akhb6GE73EA

@Kappa971 @ThreeDeeJay So I assume the problem still persists with this game and that the Airtable configuration for it is irrelevant ?

To be fair, all the DSOAL configurations on Airtable are already pointing to the recommended config (ALchemy) at the beginning of the guides, at least until this is fixed.

By the way, in case anyone needs the save file for that level:
Hitman 2 Silent Assassin - The Gontranno Sanctuary - Anathema.zip

[Phantom-Aspekt]

Just tried playing around with this again, I don't think it's an OpenAL Soft specific issue but rather a DSOAL one, if you use the latest OpenAL Soft build with the dsound.dll from DSOAL build r294, distant sounds aren't muffled. Any DSOAL build starting at r386b onward seems to have the distance muffling issue.
There is a different issue when using this r294 build of DSOAL though, it doesn't pick up when doors have been opened in game, so just walking your character through an open doorway and having the camera zoomed out makes it sound like the door is closed behind them, and any character firing at you through an open doorway will also be muffled.

I used the older DSOAL builds from here if anyone wants to try this for themselves http://vaporeon.io/hosted/dsoal-builds/old/

[ThreeDeeJay]

There is a different issue when using this r294 build of DSOAL though, it doesn't pick up when doors have been opened in game, so just walking your character through an open doorway and having the camera zoomed out makes it sound like the door is closed behind them

@Phantom-Aspekt In many games, the listener is placed on the character (usually around the head/ears) instead of the camera, so stuff between the character and the camera sounds like it's behind even though we can still see it on screen, like in Max Payne.
So are you saying that it only happens on older builds or perhaps you only noticed when using them?
also did you try the build from the rewrite branch?

[Phantom-Aspekt]

Unfortunately the one in the link you sent seems to crash for me, I'll have another look into it later.

I did record what I was talking about here though, so like I said earlier the old r294 build for dsound.dll seems to be fine distance wise with no muffling of gunshots, impacts or footsteps etc, it is just problematic with doorways as shown.
The later builds of dsound.dll for DSOAL seem to muffle the distant sounds but acts normal in doorways.

Both of these were tested with the exact same OpenAL Soft file which is from the latest binaries on https://openal-soft.org. This is why I'm thinking this might be DSOAL related and not OpenAL Soft itself, whatever changed in dsound.dll between r294 and r386 seems to have broken the distant sounds, but also fixed the doorway issue.

Hitman2_DSOAL_Test.mp4

[mirh]

If you have a regression range, then solving this should be pretty easy peasy (and if you cannot compile this yourself, there are some other in-between builds here).

But unless you find out the precise regression commit, it's kinda pointless to discuss this considering that dsoal development is on hold atm.

[Kappa971]

If it's a very old DSOAL build, I suspect it uses its "old" EAX emulation which was somewhat "untied" from OpenAL Soft which only supported EFX effects. Later the EAX emulation was rewritten in OpenAL Soft.
2 years ago I also shared the logs but apparently they weren't enough for the developer to figure out what's wrong.
Just an idea: maybe a more extensive log is needed to understand where things go wrong? As a non-developer, this is the only idea I can think of.

[ThreeDeeJay]

Apparently r386 was released way before the EAX API was added to DSOAL (from 2022) so I doubt that's it.

But yeah, if we had a build for every single commit, that would make debugging stuff like this way easier
I wonder if we could use CI to build every single version and store it somewhere reachable 🤔

[Kappa971]

Apparently r386 was released way before the EAX API was added to DSOAL (from 2022) so I doubt that's it.

DSOAL already supported EAX before this 2022 commit, but in a different way (via EFX in OpenAL Soft which did not support EAX).

But yeah, if we had a build for every single commit, that would make debugging stuff like this way easier I wonder if we could use CI to build every single version and store it somewhere reachable 🤔

This should be simple to do with Visual Studio (unless there are problems compiling older builds).

EDIT

The first build I can compile with Visual Studio 2022 is commit 1a412b93 dated May 5, 2019. This build already has the bug.

[kcat]

I wouldn't count on older versions behaving more correctly. Even if the end result sounds better, it would likely be a result of something being missing or broken.

What's really needed is to get a debug log that shows the EAX parameters being set for the sound, as well as the general properties (position, direction, cones, etc) of the sound and listener. If it's not causing a more obvious problem like a warn, fixme, or err message, that's easier said than done since games play a good number of sounds during their run (even if you can't hear anything, there can be distant ambient sounds that just end up at a low volume), which makes it very difficult to isolate the buffer relating to the bugged sound in the log to see what it specifically is doing. And when it can take a while from the game starting to the problem sound being played, it's that much more difficult to tell what sounds are what from the log.

[mirh]

Just an idea: maybe a more extensive log is needed to understand where things go wrong? As a non-developer, this is the only idea I can think of.

There's just so much you can log before somehow having to invent kinda like a new language to try to picture in words, the kind of "calculations" that are going on under the hood.

Apparently r386 was released way before the EAX API was added to DSOAL (from 2022) so I doubt that's it.

You are very much wrong. That only moved EAX from being handled inside of dsoal, to being used from openal.
(no wonder also that a lot of swings and changes happened during that summer 6 years ago, considering between a third and a half of the code was written exactly then)

The first build I can compile with Visual Studio 2022 is commit 1a412b93 dated May 5, 2019. This build already has the bug.

Shouldn't be that hard to apply that pretty simple patch to older revisions then.

I wouldn't count on older versions behaving more correctly.

To be sure, but at least we'd now know what piece of code is responsible for changing the relevant behaviour.

to the problem sound being played, it's that much more difficult to tell what sounds are what from the log.

Maybe timestamping each line could help? Then it shouldn't be too hard to figure the general neighbourhood of where the problem starts.

[ThreeDeeJay]

DSOAL already supported EAX before this 2022 commit, but in a different way (via EFX in OpenAL Soft which did not support EAX).

You are very much wrong. That only moved EAX from being handled inside of dsoal, to being used from openal.

@Kappa971 @mirh I wasn't referring to when EAX was initially supported in DSOAL, but rather the "Replace use of EFX with OpenAL's EAX API" commit (Appveyor build 1.0.28), which is known to have broken EAX in many games, some of which I think were eventually fixed, but some were not. If you want you can test that build against the previous one to see if anything changes here. But then again, both builds are much newer than r386 where muffling was already reportedly happening, which is why I doubted it'd help.

On a lighter note, I figured out how to make the CI loop through the entire commit history in reverse chronological order which could help regular users track down possible regressions, but I'm also having trouble building the older ones like the initial commit so I had to limit it to a couple newest ones, which worked.

Shouldn't be that hard to apply that pretty simple patch to older revisions then.

@mirh I'm not familiar with patches. can those be used via command line since I'm doing all this in CI?
Otherwise I think I could just pull the whole/latest file(s) directly from the repo

Also I'm not quite sure how to organize releases. Like should every commit have its own tag (e.g. r###) or should I just release them all under a generic tag and just add the version to the filename? and should I combine Win32 and Win64 pack or release them separately? And I should probably lose the separate HRTF build or just include it in a solid zip file where it'd compress well 🤔

[mirh]

You don't need really need regression testing for hrtf (I mean, the code is abstracted from the really messy black box stuff)
And tags or versions it would depend on just how well you can have them point out to the original commit in the web page I guess (but I'd be surprised if github's was so generous to let you build hundreds of revisions at once?).

Anyway yes, you can literally just use git patch <patch>.

[ThreeDeeJay]

It's not just for HRTF. There's a couple regressions I've been meaning to report but didn't have the means to conveniently track down the culprit so devs have a lead to work with.

tags or versions it would depend on just how well you can have them point out to the original commit

I considered adding the commit to the filename, but I settled for just the r### commit count for the filename so we can swap out the number in a URL to get a desired version. https://github.com/BinauralAudio/dsoal/releases
Though I did include the commit hash in the version text file like this kcat/dsoal#52 (comment)

However, when trying to link a release/tag to the respective commit, I just gotta figure out how to fix this dreaded error

I'd be surprised if github's was so generous to let you build hundreds of revisions at once

Currently the free plan allows 20 builds at a time and 256 builds max for the queue, so 2 runs and some patience should do.

[Kappa971]

If it can be helpful, this is the DSOAL c++ rewrite log: dsoal_log.txt

[kcat]

I don't suppose the latest OpenAL Soft commit 56c4602 fixes the muffled sound issue? Or at least improves it. The EAX filter calculations were wrong, but I don't think it would have too much of an effect if the sound wasn't already being filtered.

[Kappa971]

I don't suppose the latest OpenAL Soft commit 56c4602 fixes the muffled sound issue? Or at least improves it. The EAX filter calculations were wrong, but I don't think it would have too much of an effect if the sound wasn't already being filtered.

Unfortunately it doesn't seem to fix the bug. Maybe someone else could try to confirm this.

[Hiradur]

I can confirm that 56c4602 does not fix the issue.

I identified the commit that introduced the issue in DSOAL though, see kcat/dsoal#51 (comment)

[ThreeDeeJay]

If the bug is caused by DSOAL alone, perhaps this issue should be closed to continue the discussion in that DSOAL thread 👀👌

[Kappa971]

Ok I'm closing this.

[Hiradur]

In the case of Hitman: Blood Money, the fix required changes to both OpenAL Soft and DSOAL.

Could you check if Hitman 2 is now fixed as well with latest commits of OpenAL Soft and DSOAL's c++-rewrite branch?

[ThreeDeeJay]

DSOAL r557@14a8ca5 (c++-rewrite) + OpenAL Soft r9350@46df547 works on my end
https://youtu.be/SyC3aiXLz-I

[Kappa971]

DSOAL r557@14a8ca5 (c++-rewrite) + OpenAL Soft r9350@46df547 works on my end https://youtu.be/SyC3aiXLz-I

"pezzo di merda" "allarme!" with a fake Sicilian accent, I didn't know it was in the English dub too 😂