FEAR + DSOAL: EAX/EFX audio intermittently cuts in/out starting at DSOAL r444a

[AdamOSDev]

Summary

In F.E.A.R. (Steam version) using DSOAL for EAX support, audio transitions between environments behave normally up to DSOAL r444 (includes OpenAL Soft). Starting with DSOAL r444a (and all later builds, including r689), reverb and spatial effects intermittently cut in and out when crossing acoustic boundaries. The newer builds otherwise produce more accurate and realistic environmental audio (to my ears anyway) - reverb types, intensities, and spatial cues match the game's spaces better - but the wet path occasionally drops for a few milliseconds, causing noticeable flicker.

This regression appears to coincide with the EFX deferred-update and effect-slot handling changes introduced around r444a.

System

• OS: Windows 11 Pro 24H2 (build 26100.6899)
• CPU: Intel i9-13900KS
• RAM: 64 GB
• GPU: RTX 4090

Setup

• Tested with and without the 4 GB patch - no difference
• Tested with and without XP compatibility mode + running fear.exe as admin and not
• DSOAL r689 (dsound.dll) with its bundled soft_oal.dll
• Audio backend: OpenAL Soft default (WASAPI on Windows 11)
• Audio output: 48 kHz, HRTF, headphones
• In-game audio options enabled:
  • Enable HW mixing
  • Enable EAX 2.0
  • Enable EAX Advanced HD
• Default alsoft.ini used for both tests (no custom configuration)

Observed

• r444a+ builds apply reverb and spatial effects more accurately overall - environmental differences between small rooms, corridors, and open areas are clearer than before. However, the wet path intermittently drops or fades for a few milliseconds when crossing boundaries or generating new sound sources.
• In "muted" (non reverb) Armacham office areas:
  • First melee impact plays dry, then reverb cuts in milliseconds later.
  • Subsequent melee strikes may alternate between having reverb and being dry.
• Footstep reflections intermittently cut out in adjacent hallways.
• First few levels with simpler geometry sound correct in all the builds I tested.
• Behavior unchanged with reverb-emulation=0, suggesting an effect-slot routing or timing issue rather than a reverb-processing error.
• No errors in dsoal.log or alsoft.log; logs show rapid EAXPROPERTYID_EAX40_Source and FXSlot updates on r689.

Regression Range

• Last good: r444 + bundled OpenAL Soft
• First bad: r444a + bundled OpenAL Soft
• Still bad: r689 + bundled OpenAL Soft

Evidence

• YouTube videos:
  • Good (r444) - consistent reverb throughout the test area: https://youtu.be/SwQjYskWBZo?si=8gitMcg84gHKESc7
  • Bad (r689) - intermittent reverb cutouts on the same path: https://youtu.be/MIWFRO-oRy8?si=bZKOm3y7Hw081UmA
• The logs and builds used for testing are in the attached zip file.

Notes

• Each DSOAL release tested used its own bundled OpenAL Soft DLL; no cross-version mixing.
• Issue unaffected by FPS cap, buffer size, or latency.
• Rolling back to r444 immediately restores stable behavior.
• Based on the logs, I'd say the issue is somehow related to deferred-update or effect-slot swap logic introduced around r444a.

fear_dsoal_logs+builds.zip

[kcat]

What if you use the dsound.dll from r444, but the dsoal-aldrv.dll from r444a or r689?

My first thought was some change with how OpenAL Soft handles reverb environment transitions. r444 has 1.23.1 (plus a hotfix for extension functions on 32-bit Windows), while r444a has 1.24.2 (or some later commit before 1.24.3; the OpenAL dll doesn't have the exact commit hash) and r689 has the latest Git, so there could've been some change there somewhere. But looking at the dsoal logs it doesn't change the reverb environment after setting it up. It only changes the panning vectors for the reverb effect, which shouldn't be an issue.

I do see it set various EAX source properties in some kind of update loop with the deferred flag, which get applied soon after when it sets the next non-deferred property (at the beginning of the next audio update loop at the latest, where it explicitly calls CommitDeferredSettings(), and each audio update loop seeming to be roughly 90ms to 100ms apart).

If changing dsoal-aldrv.dll causes r444 to exhibit the issue with the wet path going silent, that would suggest a more general issue in OpenAL Soft's handling of source sends. If it still sounds good with changing dsoal-aldrv.dll, then it could be an issue with how DSOAL is using OpenAL.

[AdamOSDev]

What if you use the dsound.dll from r444, but the dsoal-aldrv.dll from r444a or r689?

I tried both dsoal-aldrv.dll's and experienced the same intermittent reverb cutouts with dsound.dll from r444. I captured logs for both scenarios. See attached.

logs.zip

Let me know if there is anything else you'd like me to test!

[kcat]

I did find an issue in OpenAL Soft that affected at least 1.24.2 and later, and not 1.23.1, that could cause part of the reverb buffer to be erroneously cleared when changing reverb environments. That should be fixed now with this commit, which should be included in the next DSOAL autobuild (from the Actions page, it should be listed as "Untagged build #322" or later; it probably will be about a day before its made, alternatively if you don't want to wait you can get an updated OpenAL Soft binary from its Actions page, and simply rename the appropriate soft_oal.dll to dsoal-aldrv.dll).

Though as I noted before, it doesn't look like it's actually changing the reverb environment in the logs for that to affect it, but the symptoms sound similar. If an updated OpenAL Soft does fix it, then there's another issue with OpenAL Soft applying extraneous environment transitions when it shouldn't, and if it doesn't, the issue is something/somewhere else.

[AdamOSDev]

I tested with OpenAL Soft v1.24.3-2b47394e (HRTF version) dsoal-aldrv.dll, which includes your commit (576020a - Fix clearing the old reverb pipeline buffer) with DSOAL builds r444 and r689 and still had the same issue. Logs attached

logs_20251102_1.zip

[Omarock92]

Can confirm I noticed this as well when you melee hit different objects. The first hit will always cut out early. If you keep hitting the same spot it plays fine until you hit a different spot then you get the same issue for the first hit, etc...

Edit: Just tested with DSOAL r689 + OpenAL Soft r10301 and I think it fixed it.