EAX greyed out in FEAR

[NTULINUX]

Hi,

I have the dsound.dll and dsoal-aldrv.dll files in the FEAR game directory but EAX 2.0 and Advanced HD are greyed out, any ideas? IndirectSound brings up the EAX 2.0 option, but I do not want to use this. IndirectSound only emulates EAX up to 2.0 and doesn't have the flexibility as dsoal. On this Steam discussion, it mentions that depending on the version of Windows 10 affects the usability of dsoal:

https://steamcommunity.com/app/21090/discussions/0/1739980540129531970/?ctp=2

I'd like to be able to debug this problem but there is no info about DLL injection/loading/info or any errors in terms of FEAR processing dsoal's dsound.dll file or dsoal-aldrv.dll

Both DLL files are present in the FEAR game directory. I am running Windows 10 1909 OS build 18363.535

Thank you!

[kcat]

I have heard of similar issues where newer Win10 updates were preventing dll replacements from working properly. I don't know what exactly the cause is, but one thing to check is that both DLLs are actually going into the game folder and not the virtual override folder.

[NTULINUX]

They are going into the correct folder as putting the IndirectSound DLL in place of the one for dsoal makes the EAX 2.0 option configurable. Do you have any suggestions for gathering some lower level debug info so I can dig deeper into this? I've been doing Linux development for over a decade but I'm not familiar with the Windows tools, however it's not something I can't learn. I'd like to get to the bottom of this.

If this strictly has to do with Windows 10 build versions, the least I could do is build a list of Win10 versions of which are confirmed to work or fail to load, but this doesn't help you very much, only users.

Judging from the thread, the 1903 update broke it.

Using TDM EAX also works, dsoal is the only thing not working. What do you need so I can help fix this?

Thank you!

[mirh]

Perhaps try to do some version bisection even in like a VM for starters?

[NTULINUX]

Does the dsound.dll depend on some other DLL or is everything compiled in like a static library? If 1809 works but 1903 doesn't, then some Windows file must be the root cause of the problem. dsound.dll is OS build version dependent somehow but how to narrow this down? Can you elaborate?

[mirh]

If you know for sure breakage happened between 1809 and 1903, then you can start experimenting with mixing dlls, yes.
But it could even be something with the registry or drivers, who knows.

[kcat]

Do you have any suggestions for gathering some lower level debug info so I can dig deeper into this? I've been doing Linux development for over a decade but I'm not familiar with the Windows tools, however it's not something I can't learn.

I'm not very familiar with Windows debugging either. You can set the DSOAL_LOGLEVEL environment variable to 2 or 3 when you run the app and it'll write a trace log to stderr, and optionally set DSOAL_LOGFILE to a path+filename to write the log there instead. It's not the easiest thing to deal with on Windows, but I never figured out the best way to do this kind of logging from a DLL on Windows. That'll only give you something if it's getting to load at all, but it's the best one can do from DSOAL itself.

Does the dsound.dll depend on some other DLL or is everything compiled in like a static library?

It needs at least dsoal-aldrv.dll. Other than that, it depends on the compiler's build settings. It might need a particular C runtime DLL or it might not if that was set to be static linked (or if it used the basic msvcrt.dll).

[NTULINUX]

Well this kinda sucks, all the sudden everything is working after rebooting a few more times. Some people say they needed to install ALchemy with the sound card restriction remover to set up some registry entries, I removed all of that, including the eax.dll that was placed in SysWOW64, dropped back in DSOAL into the FEAR folder in an attempt to debug this, but the problem is gone.

dsoal_log.txt:

1568:trace:dsound:load_libopenal Loaded dsoal-aldrv.dll
1568:trace:dsound:load_libopenal Found ALC_EXT_thread_local_context

Bunch of EAX info in there, so everything is working. No idea what magic happened. I was hoping I could help other users in case this happened to them. I tried installing all of this before and went through all these steps, DSOAL still wasn't working, and now it is without doing anything. If the issue comes up again, at least I know where to look. Thank you both!

FWIW, I ran sfc /scannow as well. No idea what step fixed this problem.

Closing this issue for now.

[NTULINUX]

Figured it out, FEAR has to be launched in XP compatibility mode.

[mirh]

That sounds like something to do with running as administrator or the "HardwareAudioMixer" compatibility fix.
In both cases, it still seems like a bug for the wrapper.

[Mkilbride]

Thing is, I can't run F.E.A.R in XP compatibility mode or the HD texture pack doesn't work.

[mirh]

That doesn't really make sense

[SirCanucklehead]

also having this issue. Running Fear in XP SP3 compatibility mode and still can't enable EAX.

Windows 10 v20H2

[mirh]

Did you remember to install both dsoal and openal-soft?

[mirh]

Well this kinda sucks, all the sudden everything is working after rebooting a few more times.

FWIW this "mysterious randomness" was probably the same of #34 (comment).
It just so happen that installing ALchemy does the same CLSID trick and Windows may not immediately "reload" the environment (so on the first try right off the bat it may still not work, and then after a few minutes of wait or a full reboot the magic happens).

FEAR.exe has apparently no real call to "anything audio", only loading SndDrv.dll for it.
That does in turn have no references to dsound.dll, instead completely relying on our COM friend EAXDirectSoundCreate8 inside the built-in eax.dll.

The only big question I'm left with is.. how in the hell could OP get XP compatibility mode (meaning running as admin) to work?
Only the CLSID HKLM trick could work there, but certainly something this "burdensome" would have been mentioned if any?