EAX support about openal-soft HOT 32 CLOSED

Added support for EAX 2.0-5.0 and X-RAM extensions (#632).

from openal-soft.

First off, I should mention I'm not too familiar with EAX itself. I've played around a little with EAX 2.0 that offers a single reverb effect with tweakable parameters, but hardware accelerated audio and EAX was already on the way out by the time I got into 3D audio programming.

That said, yes, EAX can be routed to EFX. EFX was designed by the same company to be a more OpenAL-like API for the same hardware functionality, since EAX was designed for DirectSound which no longer had hardware acceleration with Windows Vista. Creative tacked on an EAX extension in their OpenAL driver to expose their hardware capabilities for early OpenAL adopters. However, since the EFX API was developed, it's the preferred method of doing environmental audio, with EAX left for compatibility with those old apps.

OpenAL Soft never supported the EAX extension, since it began development with code that didn't include any environmental audio processing -- just the standard doppler shift, 3D panning, and distance/cone attenuation, over stereo output. The environmental audio had to be coded independently, and the EFX API had been designed by that time with easy-access documentation, whereas EAX docs were difficult to find. And since EAX relies on Windows-specific types (GUIDs), I decided to only worry about EFX which was platform-agnostic and the way forward for apps doing environmental audio on OpenAL.

As far as I'm aware, EFX is capable of handling up to at least the EAX 5.0 feature set. Though EFX is a bit modular, so an implementation may not have everything. For instance, you may only have a single (parameterized) I3DL2 reverb effect with per-source low-pass filters, or you may have multiple, more featured, "eax reverb" effects with per-source low-, high-, and band-pass filters, along with chorus, distortion, equalizer, and other effects. As of 1.17.2, OpenAL Soft supports most of what the EFX API defines, with up to four simultaneous effects, missing only the frequency shifter, pitch shifter (where it alters the pitch but keeps the same speed of playback), vocal morpher, and autowah effects.

Consequently, OpenAL Soft with EFX can do smooth transitions between reverb zones. You can have multiple "eax reverb" effects defined, one per nearby zone which can be panned in the direction of its aperture relative to the listener. Then as you get closer and enter the zone, it envelopes the listener as the "old" zone starts panning back toward the area you came from. Each source can feed each effect depending on how much it reaches the zone (i.e. a source inside the zone can feed it fully, while a source that's completely blocked from it can avoid feeding it at all, and a source that's only partially blocked from it can partially feed it).

from openal-soft.

@kcat What do you think about integrating this into OpenAL Soft?

from openal-soft.

Ah, thanks for such an informative reply! That makes a lot of things much clearer.
Some remaining questions about it:

1. Since EAX calls can be routed into EFX calls, is that something that could be implemented in OpenAL Soft in the future? That would help a lot of games that used EAX.
2. Is EFX supported at the same level across different platforms?
3. From your description I take it EFX is capable of ambient occlusion/obstruction too. What does it take to implement all that in game engines? For instance, Unreal (UE1) has an in-development OpenAL sound renderer as well as per-zone I3DL2 effects, but last I checked the transitions between zones were not smooth. Similarly, if my first point was realised, would EAX 3-capable games, like Unreal Tournament 2004, also retain the capability of smooth zone transitions and ambient occlusion/obstruction?

from openal-soft.

1. The biggest problem will be documentation. Like I mentioned, I don't really know much about EAX, and I'd need to get the proper values and parameter types for the properties, as well as knowing their behavior.
2. Yep. OpenAL Soft's processing is largely platform-agnostic, so as long as you have the CPU power (which it doesn't need too much of), it'll do it.
3. It should, yes. Occlusion/obstruction is implemented via low-pass filters, where it can lower the source's overall volume with extra attenuation on high frequencies, depending on what's in between the source and listener (for the direct path/output) and the source and room/zone (for the effect sends). The app is responsible for doing the line-of-sight checks and setting the appropriate volumes.

I3DL2 reverb isn't really capable of smooth zone transitions since it lacks the panning properties of the more advanced "eax reverb" effect. Such an old title like Unreal 1 probably didn't even support multiple simultaneous effects. If support is added for the EAX extension, games that used EAX 3 through OpenAL would likely still be able to do the same things it could.

from openal-soft.

All right, thanks for the information. That explains why there's no occlusion and smooth transitions in Unreal despite it using EFX, since there's most likely no code for doing line of sight checks whatsoever in the base game, it would need to be coded separately. But good to know it's doable.

It would be nice to keep this issue around as a tracker for whenever anyone attempts to implement such an EAX to EFX call translation layer.

from openal-soft.

does this means that OpenAL Soft 1.18.2 does not support EAX? i tried it in STALKER and the console says EAX extensions are not found.

from openal-soft.

Yes, it does mean it.
Unfortunately there's nobody with free time of adding them to openal soft.

from openal-soft.

At the very least maintaining support for devices that already feature EAX support would be appreciated, as that is basically the only thing preventing me from moving (system-level) from Creative OAL to OALSoft. As an example, here's oalinfo64 with my Sound Blaster X7 with Creative's OAL

openal-info64.exe
Available playback devices:
    Speakers (Sound Blaster X7)
    Generic Software on Speakers (Sound Blaster X7)
    Generic Software on Speakers (Logitech G930 Gaming Headset)
Available capture devices:
    Microphone (Logitech G930 Gamin
    What U Hear (Sound Blaster X7)
    Bluetooth (Sound Blaster X7)
    Line In (Sound Blaster X7)
    SPDIF In (Sound Blaster X7)
    USB Host (Sound Blaster X7)
    Mic-In/Mic Array (Sound Blaster
Default playback device: Speakers (Sound Blaster X7)
Default capture device: Microphone (Logitech G930 Gamin
ALC version: 268464298.0

ALC Error: Invalid Enum (0xa003), @ 199
** Info for device "Speakers (Sound Blaster X7)" **
ALC version: 1.1
ALC extensions:
    ALC_ENUMERATE_ALL_EXT, ALC_ENUMERATION_EXT, ALC_EXT_CAPTURE, ALC_EXT_EFX
HRTF extension not available
OpenAL vendor string: Creative Labs Inc.
OpenAL renderer string: Software
OpenAL version string: 1.1
OpenAL extensions:
    EAX, EAX2.0, EAX3.0, EAX4.0, EAX5.0, EAX3.0EMULATED, EAX4.0EMULATED,
    AL_EXT_OFFSET, AL_EXT_LINEAR_DISTANCE, AL_EXT_EXPONENT_DISTANCE
Resampler info not available
EFX version: 1.0
Max auxiliary sends: 2
Supported filters:
    !!! none !!!
Supported effects:
    !!! none !!!

vs latest OALSoft

openal-info64.exe
Available playback devices:
    OpenAL Soft on Speakers (Sound Blaster X7)
    OpenAL Soft on Speakers (Logitech G930 Gaming Headset)
Available capture devices:
    OpenAL Soft on Microphone (Logitech G930 Gaming Headset)
    OpenAL Soft on What U Hear (Sound Blaster X7)
    OpenAL Soft on Bluetooth (Sound Blaster X7)
    OpenAL Soft on Line In (Sound Blaster X7)
    OpenAL Soft on SPDIF In (Sound Blaster X7)
    OpenAL Soft on USB Host (Sound Blaster X7)
    OpenAL Soft on Mic-In/Mic Array (Sound Blaster X7)
Default playback device: OpenAL Soft on Speakers (Sound Blaster X7)
Default capture device: OpenAL Soft on Microphone (Logitech G930 Gaming Headset)
ALC version: 1.1

** Info for device "OpenAL Soft on Speakers (Sound Blaster X7)" **
ALC version: 1.1
ALC extensions:
    ALC_ENUMERATE_ALL_EXT, ALC_ENUMERATION_EXT, ALC_EXT_CAPTURE,
    ALC_EXT_DEDICATED, ALC_EXT_disconnect, ALC_EXT_EFX,
    ALC_EXT_thread_local_context, ALC_SOFT_device_clock, ALC_SOFT_HRTF,
    ALC_SOFT_loopback, ALC_SOFT_output_limiter, ALC_SOFT_pause_device
Available HRTFs:
    irc_1052_48000
    CIAIR_44100
    CIAIR_48000
    irc_1002_44100
    irc_1002_48000
    irc_1003_44100
    irc_1003_48000
    irc_1004_44100
    irc_1004_48000
    irc_1005_44100
    irc_1005_48000
    irc_1006_44100
    irc_1006_48000
    irc_1007_44100
    irc_1007_48000
    irc_1008_44100
    irc_1008_48000
    irc_1009_44100
    irc_1009_48000
    irc_1012_44100
    irc_1012_48000
    irc_1013_44100
    irc_1013_48000
    irc_1014_44100
    irc_1014_48000
    irc_1015_44100
    irc_1015_48000
    irc_1016_44100
    irc_1016_48000
    irc_1017_44100
    irc_1017_48000
    irc_1018_44100
    irc_1018_48000
    irc_1020_44100
    irc_1020_48000
    irc_1021_44100
    irc_1021_48000
    irc_1022_44100
    irc_1022_48000
    irc_1023_44100
    irc_1023_48000
    irc_1025_44100
    irc_1025_48000
    irc_1026_44100
    irc_1026_48000
    irc_1028_44100
    irc_1028_48000
    irc_1029_44100
    irc_1029_48000
    irc_1030_44100
    irc_1030_48000
    irc_1031_44100
    irc_1031_48000
    irc_1032_44100
    irc_1032_48000
    irc_1033_44100
    irc_1033_48000
    irc_1034_44100
    irc_1034_48000
    irc_1037_44100
    irc_1037_48000
    irc_1038_44100
    irc_1038_48000
    irc_1039_44100
    irc_1039_48000
    irc_1040_44100
    irc_1040_48000
    irc_1041_44100
    irc_1041_48000
    irc_1042_44100
    irc_1042_48000
    irc_1043_44100
    irc_1043_48000
    irc_1044_44100
    irc_1044_48000
    irc_1045_44100
    irc_1045_48000
    irc_1046_44100
    irc_1046_48000
    irc_1047_44100
    irc_1047_48000
    irc_1048_44100
    irc_1048_48000
    irc_1049_44100
    irc_1049_48000
    irc_1050_44100
    irc_1050_48000
    irc_1051_44100
    irc_1051_48000
    irc_1052_44100
    irc_1053_44100
    irc_1053_48000
    irc_1054_44100
    irc_1054_48000
    irc_1055_44100
    irc_1055_48000
    irc_1056_44100
    irc_1056_48000
    irc_1057_44100
    irc_1057_48000
    irc_1058_44100
    irc_1058_48000
    irc_1059_44100
    irc_1059_48000
    Built-In 44100hz
    Built-In 48000hz
OpenAL vendor string: OpenAL Community
OpenAL renderer string: OpenAL Soft
OpenAL version string: 1.1 ALSOFT 1.19.1
OpenAL extensions:
    AL_EXT_ALAW, AL_EXT_BFORMAT, AL_EXT_DOUBLE, AL_EXT_EXPONENT_DISTANCE,
    AL_EXT_FLOAT32, AL_EXT_IMA4, AL_EXT_LINEAR_DISTANCE, AL_EXT_MCFORMATS,
    AL_EXT_MULAW, AL_EXT_MULAW_BFORMAT, AL_EXT_MULAW_MCFORMATS, AL_EXT_OFFSET,
    AL_EXT_source_distance_model, AL_EXT_SOURCE_RADIUS, AL_EXT_STEREO_ANGLES,
    AL_LOKI_quadriphonic, AL_SOFT_block_alignment, AL_SOFT_deferred_updates,
    AL_SOFT_direct_channels, AL_SOFTX_events, AL_SOFTX_filter_gain_ex,
    AL_SOFT_gain_clamp_ex, AL_SOFT_loop_points, AL_SOFTX_map_buffer,
    AL_SOFT_MSADPCM, AL_SOFT_source_latency, AL_SOFT_source_length,
    AL_SOFT_source_resampler, AL_SOFT_source_spatialize
Available resamplers:
    Nearest
    Linear
    Cubic *
    11th order Sinc
    23rd order Sinc
EFX version: 1.0
Max auxiliary sends: 2
Supported filters:
    Low-pass, High-pass, Band-pass
Supported effects:
    EAX Reverb, Reverb, Chorus, Distortion, Echo, Flanger, Frequency Shifter,
    Pitch Shifter, Ring Modulator, Autowah, Compressor, Equalizer,
    Dedicated Dialog, Dedicated LFE

from openal-soft.

OpenAL Soft can't use the hardware's capabilities since the mix is already done before it ever gets to the sound device, so a device supporting EAX is irrelevant to OpenAL Soft supporting it. The issue isn't really the capability anyway; OpenAL Soft's effect and filter implementations can handle what EAX needs. The problem is implementing EAX's functions so that they use OpenAL Soft's effects and filters properly, and without causing unnecessary load for apps that don't use EAX.

from openal-soft.

OpenAL Soft can't use the hardware's capabilities since the mix is already done before it ever gets to the sound device

How do they do it here then? Is XA2 so conceptually different?
Or did eax.dll talk directly to some part of the creative driver?

so a device supporting EAX is irrelevant to OpenAL Soft supporting it

Fun fact: all post X-Fi soundblasters (or post EMU**** if you prefer) actually are doing all of this in-software.
They drop Sensaura's openal dll in system folder and call it a day.

from openal-soft.

How do they do it here then? Is XA2 so conceptually different?

That seems to intercept the XA2 calls, allowing it to hook their own (software/XAPO) filters on certain sounds. It doesn't seem to be using hardware.

Or did eax.dll talk directly to some part of the creative driver?

Likely, either that or some part of the app or driver talked to eax.dll for some extra information for the driver to use.

Fun fact: all post X-Fi soundblasters (or post EMU**** if you prefer) actually are doing all of this in-software.
They drop Sensaura's openal dll in system folder and call it a day.

Wouldn't be surprised. Presuming you have the processing power, it's generally easier to just write the code (or use preexisting code) to run in software than to also design or use specialized hardware to get the same task done. Creative had a habit of buying out potential competition and using the tech as their own, so using Sensaura's OpenAL on their software-based sound cards seems logical.

from openal-soft.

It doesn't seem to be using hardware.

Yes, of course. But my point was about the potential being there (not that you'd want much in this day and age, but still)

from openal-soft.

That does look interesting. How well does it sound with Doom 3/Quake 4 and other OpenAL+EAX apps compared to real hardware? Quake 4 in particular had significant problems when used through DSOAL, though it's difficult to tell if it's a problem with OpenAL Soft's effects, wrap_oal's OpenAL+EAX -> DSound+EAX wrapper, DSOAL's DSound+EAX -> OpenAL+EFX wrapper, or something else acting up.

from openal-soft.

How well does it sound with Doom 3/Quake 4 and other OpenAL+EAX apps compared to real hardware?

I don't own appropriate hardware, so it's unknown to me.

id Tech 4 based games definitely has some "out of range" bugs.

• Files with reverb parameters (efxs/*.efx) in Doom 3: Resurrection Of Evil are missing air absorption hf parameter. The engine does not set values of internal structure with reverb parameters to default values before parsing those files.
• Quake 4 and Prey (2006) sometimes tries to set occlusion value to -10500.

from openal-soft.

How well does it sound with Doom 3/Quake 4 and other OpenAL+EAX apps compared to real hardware?

I don't own appropriate hardware, so it's unknown to me.

id Tech 4 based games definitely has some "out of range" bugs.

• Files with reverb parameters (efxs/*.efx) in Doom 3: Resurrection Of Evil are missing air absorption hf parameter. The engine does not set values of internal structure with reverb parameters to default values before parsing those files.

Hello, Does that means that EAX 4.0 version of Doom 3 ROE is completely Bugged, no matter what you do ?
Even If I add missing parameters "air absorption hf" -5.0000 (which was the only value for all EFX file for doom3), reverb effect are all wrong in ROE, tested on creative card with host openAl drivers, which work great with the base game.

from openal-soft.

Doom is allegedly a particularly troubled game.
kcat/dsoal#14
LAGonauta/RetroArch@3d0893a#commitcomment-78139368
p.s. HOAL had some problems compared to ct_oal and oal-soft IIRC, but maybe I'm misremembering

from openal-soft.

Hello, Does that means that EAX 4.0 version of Doom 3 ROE is completely Bugged, no matter what you do ?
Even If I add missing parameters "air absorption hf" -5.0000 (which was the only value for all EFX file for doom3), reverb effect are all wrong in ROE, tested on creative card with host openAl drivers, which work great with the base game.

Added patch to fix "air absorption hf" issue in Doom 3 ROE.
This will initialize all reverb properties to defaults before parsing the *.efx file data.

What are other issues in ROE except the problem "air absorption hf"?

from openal-soft.

Hello, Does that means that EAX 4.0 version of Doom 3 ROE is completely Bugged, no matter what you do ?
Even If I add missing parameters "air absorption hf" -5.0000 (which was the only value for all EFX file for doom3), reverb effect are all wrong in ROE, tested on creative card with host openAl drivers, which work great with the base game.

Added patch to fix "air absorption hf" issue in Doom 3 ROE. This will initialize all reverb properties to defaults before parsing the *.efx file data.

What are other issues in ROE except the problem "air absorption hf"?

Hello, I just made a retry with fix" EFX files, It work now, I have probably put them in a wrong place the first time during my test, so adding the missing line fix the EAX issue between zone, before that eax effect were stuck after the first zone change.

I also try with your tool (vanilla game), it also fix the problem on ROE.

I don't know which solution is better, probably replacing the wrong efx file instead of reseting value everytime as the base game do not have any problem (but I don't know if your tool could have negative impact on it).

from openal-soft.

I don't know which solution is better, probably replacing the wrong efx file instead of reseting value everytime as the base game do not have any problem (but I don't know if your tool could have negative impact on it).

Handling of EFX files in the engine done while loading the level.
The impact is negligible, it's just copies 112 bytes (EAXREVERBPROPERTIES structure filled with default values) from one place to another.

from openal-soft.

reverb effect are all wrong in ROE

I hope the fix solves your problem, but what does it mean that "the reverb effect are all wrong"? I have recently played Doom 3 RoE with X-Fi and have not noticed anything, what exact problem do you notice? Maybe I was not paying attention 😆

from openal-soft.

reverb effect are all wrong in ROE

I hope the fix solves your problem, but what does it mean that "the reverb effect are all wrong"? I have recently played Doom 3 RoE with X-Fi and have not noticed anything, what exact problem do you notice? Maybe I was not paying attention 😆

This issue only occurs if you enable EAX4.0, for example in EREBUS4 map, you begin in a small airlock, the sound is muffled due to the size of the room, then you enter in a corridor the sound will have echo due to the size of the room, if you return to the airlock, the game will keep the effect of the large room (echo etc;..), especially noticable with the PNJ Voice.

With fix EFX files or the patcher, the effect change everytime you enter a new zone.

I do not have pci slot to test with my old X-fi, so perhaps old creative card (audigy 2 / X-fi) have some kind of fix inside their openAl drivers (ct_oal.dll).
With my Creative AE7 Card which use a software openAL drivers from Creative/sensaura (sens_oal.dll), the problem appears.

If you want to test just type in the console "map game\erebus4" in the DOOM3 ROE menu.
To launch the console : "X:\DOOM3.exe" +set fs_game d3xp +set com_allowconsole 1

from openal-soft.

This issue only occurs if you enable EAX4.0, for example in EREBUS4 map, you begin in a small airlock, the sound is muffled due to the size of the room, then you enter in a corridor the sound will have echo due to the size of the room, if you return to the airlock, the game will keep the effect of the large room (echo etc;..), especially noticable with the PNJ Voice.

You are describing the problem which happens when reverb properties are not initialized.
In that case "air absorption hf" value could be anything.
Though, the valid range is [-100.0 .. 0.0].

Now what happens when you enter into different "audio zone" on level, if one of the reverb property in the zone is out of range:

1. The engine calls EAXSet with all reverb parameters.
2. EAX validates all values, finds the invalid one, and returns an error.
   So in the new zone you will hear a reverb from the previous one.

from openal-soft.

This issue only occurs if you enable EAX4.0, for example in EREBUS4 map, you begin in a small airlock, the sound is muffled due to the size of the room, then you enter in a corridor the sound will have echo due to the size of the room, if you return to the airlock, the game will keep the effect of the large room (echo etc;..), especially noticable with the PNJ Voice.

With fix EFX files or the patcher, the effect change everytime you enter a new zone.

I do not have pci slot to test with my old X-fi, so perhaps old creative card (audigy 2 / X-fi) have some kind of fix inside their openAl drivers (ct_oal.dll). With my Creative AE7 Card which use a software openAL drivers from Creative/sensaura (sens_oal.dll), the problem appears.

If you want to test just type in the console "map game\erebus4" in the DOOM3 ROE menu. To launch the console : "X:\DOOM3.exe" +set fs_game d3xp +set com_allowconsole 1

You mean this?
Doom 3 2022.07.21 - 13.13.49.01.zip

from openal-soft.

On your video it look like you do not have the problem, but it's very short, perhaps if you could move a little more in the room until the pnj speak and came back to the airlock, it would be more obvious.

from openal-soft.

I can't make videos larger than 23mb.
Before recording the video, the guy had already talked (so it's been a few minutes).

I forgot to mention that I recorded the game with the X-Fi Titanium HD (ct_oal).

from openal-soft.

I can't make videos larger than 23mb. Before recording the video, the guy had already talked (so it's been a few minutes).

I forgot to mention that I recorded the game with the X-Fi Titanium HD (ct_oal).
Here I have recorded the game on my system

Link to video with bugged EAX
Link to video with the EFX file fix

Do you have the same bahaviour with a X-fi card ?

from openal-soft.

If I understand correctly, there is a bug with EAX effects with Doom 3 RoE. The X-Fi OpenAL driver apparently fixes this, Host OpenAL doesn't.
Here is a longer video (before extracting, rename the z01.zip, z02.zip and z03.zip files to z01, z02 and z03):
Doom 3 2022.07.21 - 19.00.40.01.zip
Doom 3 2022.07.21 - 19.00.40.01.z01.zip
Doom 3 2022.07.21 - 19.00.40.01.z02.zip
Doom 3 2022.07.21 - 19.00.40.01.z03.zip

from openal-soft.

Correct you do not have the bug in your video.
So yes, there's something in the X-fi OpenAL drivers that prevent the bug.
That probably the reason why they were no trace/report of this bug as the time of the game and patch 1.3 release.
Thankfully, we have a fix for that.

from openal-soft.

The X-Fi OpenAL driver apparently fixes this, Host OpenAL doesn't.
So yes, there's something in the X-fi OpenAL drivers that prevent the bug.

It does not.
The problem strictly relies on what data contains the block of memory allocated by the engine (see function Mem_Alloc in the source code).

from openal-soft.

It does not. The problem strictly relies on what data contains the block of memory allocated by the engine (see function Mem_Alloc in the source code).

I didn't mean that the X-Fi drivers fix the bug, I meant that with the X-Fi, the game works fine even if the bug is still there (in the video I uploaded, the game works fine and I didn't apply any fixes ).
If this fix can help other people, then it should be implemented in eaxefx_app_patcher. For those who have an X-Fi it is not necessary, because the game apparently works well anyway (I don't know why).

from openal-soft.

I didn't mean that the X-Fi drivers fix the bug, I meant that with the X-Fi, the game works fine even if the bug is still there (in the video I uploaded, the game works fine and I didn't apply any fixes ).

It's an intermittent/random bug. It depends on the contents of dirty memory, so it can seem to work just fine for a long time for some people, and be a regular problem for others, depending on a whole host of otherwise unrelated factors.

from openal-soft.