[Feature Request] Hardware OpenAL support for e.g X-fi cards on Linux

[nakos937]

Hello,
I know this is an edge case, but I have an Auzentech X-FI Prelude card, and I would like to use it to run old games on Proton/Wine with hardware EAX support. I could not find any info if this is possible already or any docs / stories regarding this matter, so I am at a loss.
I don't really know if the current implementation supports this or not, even, please enlighten me on this matter.
If it is not implemented, I don't really have the technical knowledge to implement something like this, but I can help with donating a card and funding.

[kcat]

OpenAL Soft doesn't use hardware processing, and there isn't any practical way for it to without writing a whole new separate library for that hardware (which may also need kernel driver enhancements to access the features of the hardware). It would have to be a completely separate project. And that's presuming it's not a software-based card that Creative's been using, in which case it would just be doing what OpenAL Soft already is.

In either case, OpenAL Soft does provide EAX features already, through software so it will work on whatever card you have regardless of OS. It can also provide EAX support for older games in Proton/Wine already, but exactly how to do that depends on the game. If the game uses OpenAL, then installing or otherwise providing the OpenAL Soft DLL and have the game use an OpenAL Soft device should work. Just make sure to use the latest release (1.22.0) which added legacy EAX API support.

If the game instead uses DirectSound3D, then you can use DSOAL which wraps DirectSound over OpenAL Soft and pretends to be hardware accelerated, using OpenAL Soft to handle 3D rendering and EAX effects (DS3D's native effects API doesn't work, though). It's essentially like ALchemy, but for OpenAL Soft instead of Creative's drivers. DSOAL may have compatibility issues with some games, but it does work for a fair number of them.

[nakos937]

Thank you for answer. Are the sound effects comparable to the hardware accelerated EAX? I had checked software implementations of EAX / OpenAL ages ago and they were quite different compared to the real deal. But if it has 100% feature parity, I can throw away my old XP box and just run stuff with Wine.

[kcat]

It won't sound identical since the methods Creative used with their hardware is closed/proprietary, and OpenAL Soft does things it's own way (particularly, OpenAL Soft prefers to be speaker-agnostic with its processing as much as it can). But the general behavior should be the same. Sounds will be panned in the same direction, even if the particular panning algorithm differs, and sounds will attenuate with distance the same way. Reverb should give a sense of the same type of environment, even if there may be audible differences with the way it's generating the echoes.

If there's any egregious differences in how OpenAL Soft and Creative's cards sound (sounds or reverb being too loud or quiet, certain reverbs sounding very off, etc), that can be something to look at improving. But in general it should be comparable.

[mirh]

Everybody here would be interested into hearing any comparison...
And reminder that there's nothing special about the hardware that software couldn't do too.

Then AFAIK this is the first time newer EAX has been implemented anywhere that isn't creative's ecosystem (except asus's GX that was even less transparent though.. and @kxproject perhaps?), so no surprise that everything else was bound to be subpar.
Putting aside that even with a X-Fi, you often don't know which is the right driver to get the proper sound in specific games versions.

Back in topic, a cursory look to the emu10k1 and ctxfi linux drivers show no mention or note about 3D sound/processing. Which I guess makes sense, since that's not something you'd want to implement in the kernel (which should only provide as much flexible and comprehensive interfaces as possible for userspace). You'd need some kind of equivalent/passthrough to ct_oal.dll to get this working.

Maybe @Conmanx360 can add something else if he's still in the loop.

[Conmanx360]

AFAIK, the ctxfi drivers for Linux only deal with routing the audio, the DSP isn't involved. The DSP on the X-Fi is the same one as all the recent cards using the ca0132 HDA codec, which I've reversed engineered and documented the instructions of here.

I don't know how the X-Fi's DSP firmware is handled, if it's uploaded on driver initialization in Windows, or if it has some default firmware on the card already.

It'd likely take quite a bit of work to make something like this happen, but if you loaded the correct firmware on the DSP, and routed the correct audio signals to the right places, it could probably work. Just depends on how much effort someone wants to put into this :) You might have a better time just improving the current software implementation to try and get it closer to what the X-Fi's DSP outputs instead, then you'd have better support for all systems

[mirh]

Uh? So ca0132 is the same of EMU20K1?
Why are they using sens_oal then?

[Conmanx360]

Likely because the DSP is sitting behind an Intel HDA front end, which doesn't allow for having enough simultaneous audio streams to make it work on the way the X-Fi did.