The Serpent Rider wrote on Yesterday, 10:10:

Creative marketing bullshit™ should be taken with a grain of salt.

I agree that there is a lot of marketing speak here. After all, it's a demo disc meant to get gamers excited about Creative's flagship product at the time.

However, we previously had people saying that 128 hardware voices was marketing bullshit as well. But thanks to Falcosoft's recently released OpenAL Test tool, it was verified that some games can and will use 100+ hardware voices on X-Fi cards. So I wouldn't dismiss Creative's claims outright, without definitive proof to the contrary.

Joseph_Joestar wrote on Yesterday, 10:19:

The Serpent Rider wrote on Yesterday, 10:10:

Creative marketing bullshit™ should be taken with a grain of salt.

I agree that there is a lot of marketing speak here. After all, it's a demo disc meant to get gamers excited about Creative's flagship product at the time.

However, we previously had people saying that 128 hardware voices was marketing bullshit as well. But thanks to Falcosoft's recently released OpenAL Test tool, it was verified that some games can and will use 100+ hardware voices on X-Fi cards. So I wouldn't dismiss Creative's claims outright, without definitive proof to the contrary.

For some more interesting performance metrics I have added the ability to display how long the OpenAL Test tool's busy loop runs. That is how long it takes creating the OpenAL context, initializing and loading the buffers with audio data and then finally freeing the buffers.
This can show from a specific aspect how well the given OpenAL implementation is optimized for performance.
Here are the results:

It can be seen that Creative's HW based OpenAL implementation is the fastest (4-5 ms).
Regarding that OpenAL Soft reports and handles 4x the amount of buffers it's pretty fast as well (39-40 ms).
The generic software implementation also uses 4x buffers compared to Audigy HW but it is much slower than 4x (238-240 ms).
And finally the Realtek supposedly HW based implementation: rtk_oal.dll. It's painfully slow (3100-3150 ms!).
(The Realtek OpenAL driver can be found in Realtek's 3DSoundBack software package.)

@Edit: rtk_oal.dll is not likely to be hardware based since:
1. When it's used the test application is detected by the Windows mixer and you can change the volume by the mixer. So it's sure that it does not bypass the Windows audio stack.
2. The same hardware under WinXP (where hardware acceleration is really available) reports only 32 hardware buffers through Direcsound3d. So the 66 buffers reported by rtk_oal.dll seems no to be related to real hardware resources.
3. When another OpenAL app uses the driver for output the 1st instance still can report 66 available buffers.

Her is the new version of OpenAL Test anyway:

Falcosoft wrote on Yesterday, 14:22:

It can be seen the Creative's HW based OpenAL implementation is the fastest (4-5 ms). Regarding that OpenAL Soft reports and han […]
Show full quote

It can be seen the Creative's HW based OpenAL implementation is the fastest (4-5 ms).
Regarding that OpenAL Soft reports and handles 4x the amount of buffers it's pretty fast as well (39-40 ms).
The generic software implementation also uses 4x the buffers compared to Audigy HW but it much slower than 4x (238-240 ms).
And finally the Realtek supposedly HW based implementation: rtl_oal.dll. It's painfully slow (3100-3150 ms!).

Big thanks, that's exactly what I wanted to find out!

ott wrote on 2026-01-23, 23:50:

Is it possible to somehow compare Creative's HW OpenAL vs OpenAL-Soft audio latency?

ott wrote on Yesterday, 14:29:

Falcosoft wrote on Yesterday, 14:22:

It can be seen the Creative's HW based OpenAL implementation is the fastest (4-5 ms). Regarding that OpenAL Soft reports and han […]
Show full quote

It can be seen the Creative's HW based OpenAL implementation is the fastest (4-5 ms).
Regarding that OpenAL Soft reports and handles 4x the amount of buffers it's pretty fast as well (39-40 ms).
The generic software implementation also uses 4x the buffers compared to Audigy HW but it much slower than 4x (238-240 ms).
And finally the Realtek supposedly HW based implementation: rtl_oal.dll. It's painfully slow (3100-3150 ms!).

Big thanks, that's exactly what I wanted to find out!

ott wrote on 2026-01-23, 23:50:

Is it possible to somehow compare Creative's HW OpenAL vs OpenAL-Soft audio latency?

Since OpenAL Soft uses WASAPI in shared mode latency cannot be lower than ~30 ms. But according to Github conversations it uses larger buffers so latency is larger in practice.

OpenAL Soft itself will add about 50ms on average, given the default 20ms period size and 60ms buffer.

https://github.com/kcat/openal-soft/issues/682

As for Audigy HW I have no justifiable data but considering that Creative's HW OpenAL driver's audio path is similar to Creative's HW ASIO driver I would guess that the latency is much better also.
(Creative's HW ASIO driver's latency is less than 10 ms if configured properly)

Falcosoft wrote on Yesterday, 14:44:

Since OpenAL Soft uses WASAPI in shared mode latency cannot be lower than ~30 ms. But according to Github conversations it uses larger buffers so latency is larger in practice.

Thanks for the addition.

It seems that low-latency audio in games aren't of much interest these days.
https://youtu.be/okIpbu1tp_A

Joseph_Joestar wrote on Yesterday, 08:19:

When I have more time, I'll try to put this on the Vogons wiki, so that it's more easily accessible.

And done! Behold our new EAX wiki page: https://www.vogonswiki.com/index.php/EAX

Still needs some polish, but most of the important info should be there.

Falcosoft wrote on Yesterday, 14:22:

For some more interesting performance metrics I have added the ability to display how long the OpenAL Test tool's busy loop runs. That is how long it takes to create of the OpenAL context, initializing and loading the buffers with audio data and then finally freeing the buffers.

Cheers! This should make for some interesting comparisons, especially against period correct on-board audio solutions (Realtek).

There's a KillDrvX.exe utility bundled in latest Audigy Support Pack 8.1. If you run it, it says:

The driver currently installed is affected by a bug that crashes Windows when disabled or uninstalled.

To workaround this issue, the CTAUD2K service must be disabled.

Daniel K's blog notes:

Driver uninstall on Windows Vista or later (affects all cards, except Audigy 5/RX SB1550 and Audigy 4 Series II SB0612):
- The included driver for Windows Vista or later has a bug that causes a stop (blue screen) error when unloaded by disabling the Audigy or uninstalling the driver. To workaround this issue, run the KillDrvX.exe utility included and restart when asked to do so. Proceed normally and uninstall all the software or only the driver.

But, stopping the CTAUD2K driver through System Informer or Process Hacker crashes both Win11 and XP. And I have Audigy Rx. Are there different versions of this card?

I haven't tried uninstalling specifically though, was hoping to find a way to reset the driver without rebooting.

Correction: Win11 doesn't allow stopping CTAUD2K through System Informer. It crashes in ctoss2k.sys when disabling the card in Device Manager though. I forgot where it crashed in XP.

It looks like the community at OldUnreal released a new patch for Unreal Tournament 2004. The question is whether you can still use the EAX 5.0 patch with it. If anybody tries it, please report back here!

While researching something else, I accidentally stumbled upon an older version of Creative's EAX website.

This one is from 2003, and it describes EAX 3.0 and EAX 4.0 features in a more technical manner, without the marketing gobbledygook. I've incorporated these descriptions into the new EAX page on the Vogons wiki, and used Creative's old site as reference.

AndreaColombo86 wrote on Yesterday, 23:37:

It looks like the community at OldUnreal released a new patch for Unreal Tournament 2004. The question is whether you can still use the EAX 5.0 patch with it. If anybody tries it, please report back here!

They use cross-platform libs like SDL (it has audio engine with basic features) and the patch is designed for modern compilers/builds (requires Windows 7+).
This probably makes EAX APIs incompatible. I haven't tested it yet, but I'll be happy to be wrong.

Joseph_Joestar wrote on Today, 00:09:

This one is from 2003, and it describes EAX 3.0 and EAX 4.0 features in a more technical manner, without the marketing gobbledygook.

It's better to refer to technical docs from the EAX 4.0 SDK, I recently found them on the kX driver's GitHub:
EAX 4.0 Introduction (2003).pdf
EAX 4.0 Programmer's Guide (2003).pdf
EAX 4.0 Sound Designer's Guide (2003).pdf

ott wrote on Today, 01:28:

It's better to refer to technical docs from the EAX 4.0 SDK, I recently found them on the kX driver's GitHub: EAX 4.0 Introducti […]
Show full quote

It's better to refer to technical docs from the EAX 4.0 SDK, I recently found them on the kX driver's GitHub:
EAX 4.0 Introduction (2003).pdf
EAX 4.0 Programmer's Guide (2003).pdf
EAX 4.0 Sound Designer's Guide (2003).pdf

Thanks! I already referenced the EAX 2.0 SDK where applicable (e.g. for Obstruction and Occlusion) so I'm sure this one will be useful as well.

BTW, it seems that we're missing a document from the EAX 4.0 SDK. I found several references to an "EAX Unified API guide" but there's no such document on that repo at least. Would be nice if someone could dig it up, as many games from the mid 2000s used EAX Unified in order to run on integrated audio solutions (Realtek).

Joseph_Joestar wrote on Today, 05:57:

Would be nice if someone could dig it up, as many games from the mid 2000s used EAX Unified in order to run on integrated audio solutions (Realtek).

I found old doc in EAX 2.0 SDK, but to be honest I don't understand much about it.

ott wrote on Today, 12:10:

I found old doc in EAX 2.0 SDK, but to be honest I don't understand much about it.

Cheers! I imagine there's an updated version of that in the EAX 4.0 SDK somewhere, but we'd have to find the full archive.

And yeah, EAX Unified was around for a long time. I think Final Fantasy 8 (PC version) was one of the first games that shipped it on the disc back in January of 2000. Originally, it allowed EAX 1.0 capable cards to make partial use of EAX 2.0 features. But it became a lot more popular during the mid 2000s, because Creative made EAX 3.0/4.0/5.0 proprietary, so third-party sound solutions were limited to EAX 2.0. Newer versions of EAX Unified could slightly help with that, but the results weren't always great on non-Creative hardware.

It would be great if we could get access to the later versions of the EAX SDK, so we could make sure that as much of the software-understanding needed to keep using EAX is not hidden away and lost to time. Unfortunately, CL hid the later versions of the SDK behind corporate walls, so you could only get access to it through them.