[Discussion] Implementation of EAX extensions in OpenAL Soft

[Kappa971]

First of all, thank you for the amazing work you are doing. I opened this "issue", or rather, discussion to understand and allow other people to understand what this change will entail in practice. What I would like to ask is: implementing EAX extensions in OpenAL Soft means that, in games that use EAX via OpenAL, EAXEFX is no longer needed, right? For DirectSound games, will any changes be needed in DSOAL?

[mirh]

Yes, eaxefx getting merged means openal-soft will include it. This has nothing to do with DSOAL, which already comes with its own code for eax, and only uses openal for final output. I had already said this in https://github.com/kcat/openal-soft/pull/632#issuecomment-1008747266

[Kappa971]

This has nothing to do with DSOAL, which already comes with its own code for eax, and only uses openal for final output.

That's just what I was wondering, if DSOAL's EAX implementation at that point will be removed to use OpenAL Soft's. If it were possible I imagine it would reduce the code maintenance work by the developers. But I'm not a developer, maybe it's not feasible.

[kcat]

That's just what I was wondering, if DSOAL's EAX implementation at that point will be removed to use OpenAL Soft's. If it were possible I imagine it would reduce the code maintenance work by the developers.

Possibly. I'm completely in the dark when it comes to how the EAX API is supposed to work, so what I ended up doing with DSOAL is finding the similarities between it and EFX and, also working with my understanding of DirectSound, worked out a logical mapping for functionality. Start with that, and add in a bunch of trial and error, comparing the output of DSOAL vs Native or Alchemy and tweaking things to make DSOAL sound more similar, and that's how I got EAX2 in fairly decent shape. EAX3 and 4 have proven to be more complicated, particularly when it comes to the obstruction/occlusion/exclusion filters and multiple FX slots, which still has issues.

This project, on the other hand, looks much more mature, with an implementation that seems to know what it's doing, instead of being a mess of tweaks and hacks built on top of each other. It even gets EAX5 which DSOAL hasn't touched yet. Presuming there's no hidden pitfalls to map DSound EAX to OpenAL EAX (which I doubt, since it seems to be what Alchemy does), and this implementation holds up with various games, it would make sense to drop DSOAL's EAX and use OpenAL Soft's. The alternative would be to copy it out of OpenAL Soft and into DSOAL, but that seems like unnecessary duplication and extra work since DSOAL basically relies on OpenAL Soft at this point anyway.

[Kappa971]

I will look forward to further developments :)

[mirh]

Didn't you mention that you can't use the same openal dll because of the global state of contexts?

p.s. I don't believe directsound ever supported EAX 5.

[Kappa971]

Didn't you mention that you can't use the same openal dll because of the global state of contexts?

I don't know what this problem is, but in case renaming soft_oal.dll to dsoal-aldrv.dll (as you do right now) should avoid any problems.

p.s. I don't believe directsound ever supported EAX 5.

I also think there are no DirectSound games that use EAX 5.0, but in this case I think it is necessary for OpenAL games that use it (Prey, Quake 4, etc).

[kcat]

Didn't you mention that you can't use the same openal dll because of the global state of contexts?

It can't use the same filename. OpenAL32.dll and dsoal-aldrv.dll themselves can be the same, but they need to be different filenames so Windows gives them different global state.

[Kappa971]

EAX extensions have been added in OpenAL Soft, thanks to @kcat and @bibendovsky! Hope @bibendovsky can help with DSOAL too :)

[mirh]

I see.. and yeah, code duplication seems kinda uncalled for (even though there are git subtrees that could simplify the matter, and it could come in somewhat handy if EAX_AL and EAX_DS weren't to be 1:1 the same). Also, it would be funny to use dsoal with ct_oal or sens_oal.

But I cannot avoid to think this is also putting some extra duplication on the side of the users. Maybe the best of both worlds would be if just like in alchemy there was a DisableNativeAL toggle here too. But I'm spitballing by now I guess.

[Kappa971]

The only thing I can hope for is a DirectSound wrapper that points to the new EAX implementation of OpenAL Soft, otherwise I can't say anything because I don't have the necessary knowledge.

ct_oal and sens_oal let them die in peace :)

EDIT I did a quick test with the new OpenAL Soft with Prey, Doom 3 and Quake 4, just a few minutes to see if EAX worked and was recognized, it seems to work. While EAXEFX is no longer needed, with these three games, you need to run eaxefx_app_patcher.exe to fix some bugs (this is what I understand). Anyway you did a great job, I'm waiting for any improvements to DSOAL, after which the Creative cards will only be useful as a paperweight :) Thanks!

[vlad54rus]

Where is the 64 bit build? Release page only has 32 bit one.

[bibendovsky]

Where is the 64 bit build? Release page only has 32 bit one.

Added 64-bit build for the latest release.

[Kappa971]

Where is the 64 bit build? Release page only has 32 bit one.

I don't think there are 64-bit OpenAL games that use EAX, so 32-bit EAXEFX is enough for EAX OpenAL games (as they are all 32-bit games). If anyone knows of an OpenAL 64 bit game using EAX, forget what I wrote 😄 (I can only think of Serious Sam Fusion/4, but these I think use EFX). Also if you compile OpenAL Soft from source (from the GitHub repository), EAXEFX is not required.

[vlad54rus]

Nope, Fusion still uses EAX.

[Kappa971]

Nope, Fusion still uses EAX.

Serious Sam Fusion came out in 2017 and I'm pretty sure it doesn't use EAX, most likely it uses EFX. EAX died many years ago.

[bibendovsky]

Serious Sam Fusion came out in 2017 and I'm pretty sure it doesn't use EAX, most likely it uses EFX. EAX died many years ago.

It uses EAX2 as additional sound backend.

[Kappa971]

It uses EAX2 as additional sound backend.

Rather strange choice by the developers, why choose a technology that is no longer officially supported by any sound card?

[mirh]

Because presumably it was already there in the original codebase, it didn't cause any problem on recompile (even though I'm not sure what 64 bit library they linked against) and unlike valve they aren't just dropping old stuff just because.

[vlad54rus]

Yeah, OpenAL with EAX was there ever since Serious Sam 2.

[Kappa971]

It is really fantastic the work @kcat is doing in OpenAL Soft and DSOAL. DSOAL should now use OpenAL Soft's new EAX implementation. I haven't tried the latest builds yet as it's all still in development and probably something is still missing. Anyway, when the development is complete, @kcat (thanks also to the contribution of @bibendovsky) will have saved the sound of hundreds of old video games!

Ah and thanks Creative for releasing the source codes (I'm sarcastic here 😁).

[mirh]

https://github.com/kcat/dsoal/issues/46 shows indeed the "practical" merit of dsoal using openal-soft's eax

[Kappa971]

Hi @bibendovsky and first of all I apologize for mentioning you several times in another discussion. I recently bought a SB X-Fi Titanium, to be able to make practical comparisons in EAX games with OpenAL Soft. I have to admit that OpenAL Soft is pretty damn close to the X-Fi, I've noticed differences with the reverb (in addition to the Hitman 2 issues), but it will definitely be the way to go when Microsoft breaks the X-Fi's drivers again with a new Windows update 😁. OpenAL Soft only lacks an "HRTF" for stereo speakers like the X-Fi's CMSS-3D.

There is an issue that has plagued the X-Fi Titanium since 2012 (with drivers 2.40.00xx for Windows 8/10) and concerns the OpenAL stream buffer (which Creative never solved, but it doesn't surprise me). The problem appears to be that the card doesn't clear the stream buffer and becomes unable to play new sounds. I can't tell you more about it because I'm not a programmer, but this workaround was created in Retroarch to overcome this problem: https://github.com/LAGonauta/RetroArch/commit/3d0893a418cc83af9f9ac8c542e7422c8175d8eb#commitcomment-76593696. I wanted to ask you if this workaround (or something similar) can be applied perhaps as a wrapper between the game and the OpenAL32.dll router that intercepts the game's OpenAL traffic in order to compensate this bug.

Obviously if this is too complex to implement, it doesn't matter, I don't want to waste your time, but if this is a simple solution, it would allow us to use the hardware capabilities of this card as long as it works. Thanks.

EDIT In the Unreal 2 log file, for example, there are the following errors (repeated several times):

Log: ALAudio: AL_INVALID_OPERATION in RegisterSound (generating buffer)
Log: ALAudio: AL_INVALID_OPERATION in Creating streaming buffer.

with the result that after some time there will be sounds that disappear. The games that use ALchemy, for example, don't have this issue probably because the sound buffers are managed by ALchemy.

[bibendovsky]

I wanted to ask you if this workaround (or something similar) can be applied perhaps as a wrapper between the game and the OpenAL32.dll router that intercepts the game's OpenAL traffic in order to compensate this bug.

I could try to make a test wrapper (OpenAL32.dll) to "kick" a "stuck" streaming sound(s) in the separate execution thread.

[Kappa971]

I could try to make a test wrapper (OpenAL32.dll) to "kick" a "stuck" streaming sound(s) in the separate execution thread.

If it works, that would be great! It would fix a longstanding issue and allow us to use Creative's OpenAL driver (ct_oal.dll 32 and 64 bit) even with some native OpenAL games that are having problems today due to this Creative driver bug.

[bibendovsky]

I could try to make a test wrapper (OpenAL32.dll) to "kick" a "stuck" streaming sound(s) in the separate execution thread.

If it works, that would be great! It would fix a longstanding issue and allow us to use Creative's OpenAL driver (ct_oal.dll 32 and 64 bit) even with some native OpenAL games that are having problems today due to this Creative driver bug.

Added the project for a wrapper. You can discuss and to download the test build here.

[CodingPigFromTheBushes]

I tried this dll here to get OpenAL and EAX HD unlocked in Quake 4 but for whatever reason the game always says that my soundcard doesn't support OpenAL and I cannot activate it. I followed the instructions to the letter. Copied the OpenAL32.dll, openal_soft.dll into the dir of the Quake 4 exe and also used the patcher. I also tried various openal_soft and dsoal dlls to no avail. I am on latest Windows 10, got both the official Creative OpenAL driver aswell as latest Open AL Soft dlls in System32 and Syswow64. Furthermore I have a Creative SoundblasterX G6 and latest driver. EAX and OpenAL usually work fine in other games either with Alchemy or OpenAL itself but so far I had no luck with Quake 4. Come to think of it, I think Doom 3 and Prey had the same problem. Anybody got any idea?

[Kappa971]

I tried this dll here to get OpenAL and EAX HD unlocked in Quake 4 but for whatever reason the game always says that my soundcard doesn't support OpenAL and I cannot activate it. I followed the instructions to the letter. Copied the OpenAL32.dll, openal_soft.dll into the dir of the Quake 4 exe and also used the patcher. I also tried various openal_soft and dsoal dlls to no avail. I am on latest Windows 10, got both the official Creative OpenAL driver aswell as latest Open AL Soft dlls in System32 and Syswow64. Furthermore I have a Creative SoundblasterX G6 and latest driver. EAX and OpenAL usually work fine in other games either with Alchemy or OpenAL itself but so far I had no luck with Quake 4. Come to think of it, I think Doom 3 and Prey had the same problem. Anybody got any idea?

I think you got a little confused... You have a Sound Blaster X G6, so it has a proprietary OpenAL driver, it's called Host OpenAL, and it "emulates" EAX (although it does it pretty badly). Sound card drivers should automatically install Host OpenAL ("sens_oal.dll") in C:\Windows\SysWOW64 (32-bit dlls) and C:\Windows\System32 (64-bit dlls ) but it doesn't because of an old bug that was never fixed (Host OpenAL and ALchemy are no longer in development), so you have to manually copy sens_oal.dll to the paths specified above. These are the files to copy to SysWOW64 (32 bit) and System32 (64 bit): HostOpenAL.zip If you also replaced the OpenAL32.dll file in SysWOW64 and System32, you need to install this as well: oalinst.zip Once this is done, you should have your card's official OpenAL drivers working (although, as mentioned, EAX is poorly emulated).

If you want to use OpenAL Soft instead of Host OpenAL, just copy soft_oal.dll (OpenAL Soft) to the folder where the game executable is located and rename it to OpenAL32.dll.

[CodingPigFromTheBushes]

WOW! This actually did it! Thanks so much, properly works in the games now. Weirdly enough I have never heard of Host OpenAL before. Wish I knew this earlier.

[rinv]

Do the patches for Doom 3 work with CstDoom3? I believe I have followed all the steps correctly and put the files in the correct folders etc, but when I enable EAX in Doom 3 it auto reverts back to off after restarting the game (even if I set the openal flag in doomconfig), and in CstDoom3 when I enable it does stay enabled, and the patcher shows that the files are patched, but I still get the visual twitch bug. Not sure if I'm even barking up the wrong tree by testing with CstDoom3.

[bibendovsky]

Do the patches for Doom 3 work with CstDoom3?

No, the patch works only with vanilla executable v1.3.1.