-
Notifications
You must be signed in to change notification settings - Fork 531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[EAX] Hitman 2 SA (v1.01) muffled gunshots #714
Comments
I think I've found the culprit: by turning off the chorus effect in OpenAL Soft, the gunshot sound works fine. EDIT EDIT2 |
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. |
Unfortunately this is what is happening, maybe there is a bug somewhere in the chorus effect? 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 😅 |
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). |
I await further developments, I'm available to test and close this issue 🙂 |
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?). |
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. |
This make sense.
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). |
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. |
Perhaps, if the door sound is a 3D/world sound like gunshots, it may be triggering the same issue as the gunshot sounds. |
Check out #714 (comment) |
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. |
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 👏 |
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 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. |
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. 👌 |
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.
DSOAL + OpenALSoft: X-Fi TiHD ALchemy + Creative OpenAL + CMSS-3D: |
Double-check that |
D*ng it, my bad, @Kappa971 is right. I jumped the gun here.
|
|
Please, forget my misplaced blame/hope.
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. |
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? 😅 |
@Kappa971 @ThreeDeeJay So I assume the problem still persists with this game and that the Airtable configuration for it is irrelevant ? |
Sadly, yes, as of the latest build: https://youtu.be/akhb6GE73EA
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: |
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. I used the older DSOAL builds from here if anyone wants to try this for themselves http://vaporeon.io/hosted/dsoal-builds/old/ |
@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. |
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. 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 |
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. |
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. |
But yeah, if we had a build for every single commit, that would make debugging stuff like this way easier |
DSOAL already supported EAX before this 2022 commit, but in a different way (via EFX in OpenAL Soft which did not support EAX).
This should be simple to do with Visual Studio (unless there are problems compiling older builds). The first build I can compile with Visual Studio 2022 is commit 1a412b93 dated May 5, 2019. This build already has the bug. |
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 |
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.
You are very much wrong. That only moved EAX from being handled inside of dsoal, to being used from openal.
Shouldn't be that hard to apply that pretty simple patch to older revisions then.
To be sure, but at least we'd now know what piece of code is responsible for changing the relevant behaviour.
Maybe timestamping each line could help? Then it shouldn't be too hard to figure the general neighbourhood of where the problem starts. |
@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.
@mirh I'm not familiar with patches. can those be used via command line since I'm doing all this in CI? Also I'm not quite sure how to organize releases. Like should every commit have its own tag (e.g. r |
You don't need really need regression testing for hrtf (I mean, the code is abstracted from the really messy black box stuff) Anyway yes, you can literally just use |
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.
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 However, when trying to link a release/tag to the respective commit, I just gotta figure out how to fix this dreaded error
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. |
If it can be helpful, this is the DSOAL c++ rewrite log: dsoal_log.txt |
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. |
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) |
If the bug is caused by DSOAL alone, perhaps this issue should be closed to continue the discussion in that DSOAL thread 👀👌 |
Ok I'm closing this. |
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 |
"pezzo di merda" "allarme!" with a fake Sicilian accent, I didn't know it was in the English dub too 😂 |
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
The text was updated successfully, but these errors were encountered: