-
Notifications
You must be signed in to change notification settings - Fork 4
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
[Discussion] Implementation of EAX extensions in OpenAL Soft #24
Comments
Yes, eaxefx getting merged means openal-soft will include it. |
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. |
I will look forward to further developments :) |
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. |
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.
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). |
It can't use the same filename. |
EAX extensions have been added in OpenAL Soft, thanks to @kcat and @bibendovsky! |
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). But I cannot avoid to think this is also putting some extra duplication on the side of the users. |
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 |
Where is the 64 bit build? Release page only has 32 bit one. |
Added 64-bit build for the latest release. |
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). |
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. |
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? |
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. |
Yeah, OpenAL with EAX was there ever since Serious Sam 2. |
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 😁). |
kcat/dsoal#46 shows indeed the "practical" merit of dsoal using openal-soft's eax |
Hi @bibendovsky and first of all I apologize for mentioning you several times in another discussion. 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: LAGonauta/RetroArch@3d0893a#commitcomment-76593696. 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
with the result that after some time there will be sounds that disappear. |
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. |
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... If you want to use OpenAL Soft instead of Host OpenAL, just copy |
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. |
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. |
No, the patch works only with vanilla executable v1.3.1. |
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?
The text was updated successfully, but these errors were encountered: