shevalier wrote on 2026-01-14, 13:39:

Right here on this screenshot, you can clearly see how many buffers Prey uses.

Is it 127 in the first screenshot? Or 92 in the second one? Not sure I understand what you mean.

Do you need to use this tool while the game is running and it will show you the number of hardware voices that are currently used? If so, it might depend when the test was conducted. For example, there isn't much going on at the very start of Prey, since you're basically walking around a bar. Perhaps measuring it at some point when you get into a firefight with the enemies would give a slightly different result?

Joseph_Joestar wrote on 2026-01-14, 13:46:

shevalier wrote on 2026-01-14, 13:39:

Right here on this screenshot, you can clearly see how many buffers Prey uses.

Is it 127 in the first screenshot? Or 92 in the second one? Not sure I understand what you mean.

Do you need to use this tool while the game is running and it will show you the number of hardware voices that are currently used? If so, it might depend when the test was conducted. For example, there isn't much going on at the very start of Prey, since you're basically walking around a bar. Perhaps measuring it at some point when you get into a firefight with the enemies would give a slightly different result?

I give up, Creative Lab in advertising has always told the truth.

shevalier wrote on 2026-01-14, 14:04:

I give up, Creative Lab in advertising has always told the truth.

And I give up on trying to get any direct answers from you.

You quoted my questions, didn't answer any of them, and then responded with an unrelated screenshot of RightMark 3DSound asif that's somehow the solution. Great job man.

I'm also not convinced that AIDA64 correctly detects the number of hardware voices that are currently being used by a game. For example, here's a screenshot of me running Prey on Win10 while using AIDA64 in the background.

The number of "Hardware Sound Buffers" remains at 127 whether I'm actually running the game, or just idling on the desktop.

shevalier wrote on 2026-01-14, 13:25:

Maxim Liadov: Our readers would like to know when X-Fi patch for UT 2004 will be released. Darragh O'Toole: As you know, we hav […]
Show full quote

MattRocks wrote on 2026-01-14, 13:15:

[…]
Show full quote

• OpenAL is a dedicated sound mixer library, and it probably is better than Doom3 hand-rolled code.
• OpenAL is a generic sound mixer for any sound card.
• Creative distributed OpenAL with EAX, but you can enable OpenAL and disable EAX.

Maxim Liadov: Our readers would like to know when X-Fi patch for UT 2004 will be released.

Darragh O'Toole: As you know, we have a patch that was custom designed by Creative for UT2004, this features custom sound sets implemented using our developer tool ISACT for streamlined implementation of 3D audio in game. This allows us to take advantage of the higher voice count and generate higher quality sounds for two aspects of the game. Firstly, it allows the music to respond to the situation, so when your health goes down, the soundtrack switches to one of a series of levels from upbeat, to mid-tempo to panic stations (in a similar vein to the initial aims of Direct Music but which was based on Midi). Secondly, it allows the in-game sounds to use up to 24 bit stereo samples, replacing the low quality 8-bit, 11kHz sounds that most games use to preserve resources. Just as we were about to release this, Epic updated the game so we need to tweak the patch for the new version. We are in the final stages and hope to have it available for download sometime in March. Some of the new weapons sounds will definitely remind you that your subwoofer is still working!
http://ixbtlabs.com/articles2/multimedia/crea … -interview.html
Only Creative Lab knew how to write this code (optimised for OpenAL and X-FI).
That was enough for a couple of projects.
And that's it.

"Just as we were about to release this, Epic updated the game so we need to tweak the patch for the new version," shows that these releases were not collaborative partnerships.

These are custom interventions designed by Creative to showcase protest the importance of audio, not designed by Epic to showcase the importance of gameplay or the UT2004 game.

Note also the changes are to the game content (e.g. high-bit samples instead of low-bit samples*), which are not changes to how the hardware is being used.

In other words, the patch sounds better because it ships better audio assets and better mixing. But, those two changes would work with any EAX or non-EAX sound card.

“Only Creative knew how to write this code,” underscores that Creative were isolated. It shows that nobody else knew how to use Creative libraries. Instead of Epic testing their product against Creative libraries, Creative's after-market modifications broke when Epic updated the game.

I blame Microsoft. I much prefer being able to swap game hardware and get a different game audio experience, like changing an instrument. But, after the Xbox, only those who were part of the Xbox platform could be gifted gaming influence. That is business.

* In the real-world, a valid question is what is the lowest-bit sample rate that is not perceptibly different? This matters to gameplay because low-bit samples can load faster from disk/network.

Joseph_Joestar wrote on 2026-01-14, 15:04:

I'm also not convinced that AIDA64 correctly detects the number of hardware voices that are currently being used by a game. For example, here's a screenshot of me running Prey on Win10 while using AIDA64 in the background.

The attachment AIDA64_Prey.jpg is no longer available

The number of "Hardware Sound Buffers" remains at 127 whether I'm actually running the game, or just idling on the desktop.

My view is that you need to rollback to WinXP (or earlier) to activate the hardware voices because Microsoft disabled all hardware DSP features in games with the launch of Windows Vista.

Audio is not like graphics where capabilities clearly change with DX releases. Audio is a more confusing stack of mechanisms and contracts between components. In a nutshell, Microsoft withdrew the contract that audio DSPs rely on with the launch of Vista.

You can still use an audio DSP after Vista, but only with ASIO drivers. ASIO is used by professional audio work where exactly one app is locked to one sound card, and the sound card is pulling data on its own terms with its own strict timings. ASIO is not fit for a multitasking environment where many interactive apps are each pushing their own audio streams.

I doubt any EAX card has an ASIO driver, and I doubt any game supports ASIO either. My guess is that if we used ASIO then the sound card would fix frame rates 😉

MattRocks wrote on 2026-01-14, 16:06:

My view is that you need to rollback to WinXP (or earlier) to activate the hardware voices because Microsoft disabled all hardwa […]
Show full quote

Joseph_Joestar wrote on 2026-01-14, 15:04:

I'm also not convinced that AIDA64 correctly detects the number of hardware voices that are currently being used by a game. For example, here's a screenshot of me running Prey on Win10 while using AIDA64 in the background.

The attachment AIDA64_Prey.jpg is no longer available

The number of "Hardware Sound Buffers" remains at 127 whether I'm actually running the game, or just idling on the desktop.

My view is that you need to rollback to WinXP (or earlier) to activate the hardware voices because Microsoft disabled all hardware DSP features in games with the launch of Windows Vista.

Audio is not like graphics where capabilities clearly change with DX releases. Audio is a more confusing stack of mechanisms and contracts between components. In a nutshell, Microsoft withdrew the contract that audio DSPs rely on with the launch of Vista.

You can still use an audio DSP after Vista, but only with ASIO drivers. ASIO is used by professional audio work where exactly one app is locked to one sound card, and the sound card is pulling data on its own terms with its own strict timings. ASIO is not fit for a multitasking environment where many interactive apps are each pushing their own audio streams.

I doubt any EAX card has an ASIO driver, and I doubt any game supports ASIO either. My guess is that if we used ASIO then the sound card would fix frame rates 😉

Your view is not valid. OpenAL has nothing to do with the Vista+ Directsound related changes. In Vista Directsound just like the WaveOut API has become a compatibility layer above WASAPI and thus you can no longer use Directsound hardware buffers. Directsound(3d) hardware acceleration was the feature that has become unavailable from Vista. OpenAL is a completely different audio API that does not depend directly on Directsound(3d) and thus in theory can work the same way on Vista+ as on Win XP.

Falcosoft wrote on 2026-01-14, 17:13:

MattRocks wrote on 2026-01-14, 16:06:

My view is that you need to rollback to WinXP (or earlier) to activate the hardware voices because Microsoft disabled all hardwa […]
Show full quote

Joseph_Joestar wrote on 2026-01-14, 15:04:

I'm also not convinced that AIDA64 correctly detects the number of hardware voices that are currently being used by a game. For example, here's a screenshot of me running Prey on Win10 while using AIDA64 in the background.

The attachment AIDA64_Prey.jpg is no longer available

The number of "Hardware Sound Buffers" remains at 127 whether I'm actually running the game, or just idling on the desktop.

My view is that you need to rollback to WinXP (or earlier) to activate the hardware voices because Microsoft disabled all hardware DSP features in games with the launch of Windows Vista.

Audio is not like graphics where capabilities clearly change with DX releases. Audio is a more confusing stack of mechanisms and contracts between components. In a nutshell, Microsoft withdrew the contract that audio DSPs rely on with the launch of Vista.

You can still use an audio DSP after Vista, but only with ASIO drivers. ASIO is used by professional audio work where exactly one app is locked to one sound card, and the sound card is pulling data on its own terms with its own strict timings. ASIO is not fit for a multitasking environment where many interactive apps are each pushing their own audio streams.

I doubt any EAX card has an ASIO driver, and I doubt any game supports ASIO either. My guess is that if we used ASIO then the sound card would fix frame rates 😉

Your view is not valid. OpenAL has nothing to do with the Vista+ Directsound related changes. In Vista Directsound just like the WaveOut API has become a compatibility layer above WASAPI and thus you can no longer use Directsound hardware buffers. Directsound(3d) hardware acceleration was the feature that has become unavailable from Vista. OpenAL is a completely different audio API that does not depend directly on Directsound(3d) and thus in theory can work the same way on Vista+ as on Win XP.

OpenAL is not EAX. Screenshot just for you 😉

OpenAL and DS3D both typically end at software WASAPI. In theory OpenAL can offload odds and end to hardware, but that offloading is very limited and bespoke and not comparable to what WinXP did pre-WASAPI. What main thing that OpenAL can re-enable on Vista is EAX reverb.

MattRocks wrote on 2026-01-14, 18:29:

OpenAL and DS3D both typically end at software WASAPI. In theory OpenAL can offload odds and end to hardware, but that offloading is very limited and bespoke and not comparable to what WinXP did pre-WASAPI. What main thing that OpenAL can re-enable on Vista is EAX reverb.

Like Falcosoft said, OpenAL is an API. It can access Creative's hardware directly, per their ALchemy FAQ:

Creative Labs wrote:

I have a game that supports OpenAL. Do I need to use Creative ALchemy?

No, OpenAL has direct access to our hardware and does not require the ALchemy wrapper.

Under Vista and up, Creative ALchemy is used to translate DirectSound3D into OpenAL calls, which allows supported DirectSound3D games to use Creative's hardware for EAX on that OS. This too is stated in the FAQ.

Joseph_Joestar wrote on 2026-01-14, 19:03:

Like Falcosoft said, OpenAL is an API. It can access Creative's hardware directly, per their ALchemy FAQ: […]
Show full quote

MattRocks wrote on 2026-01-14, 18:29:

OpenAL and DS3D both typically end at software WASAPI. In theory OpenAL can offload odds and end to hardware, but that offloading is very limited and bespoke and not comparable to what WinXP did pre-WASAPI. What main thing that OpenAL can re-enable on Vista is EAX reverb.

Like Falcosoft said, OpenAL is an API. It can access Creative's hardware directly, per their ALchemy FAQ:

Creative Labs wrote:

I have a game that supports OpenAL. Do I need to use Creative ALchemy?

No, OpenAL has direct access to our hardware and does not require the ALchemy wrapper.

Under Vista and up, Creative ALchemy is used to translate DirectSound3D into OpenAL calls, which allows supported DirectSound3D games to use Creative's hardware for EAX on that OS. This too is stated in the FAQ.

What Creative did needs to be consistent with Daniel_K–modified drivers do, otherwise you'd be having your cake and eating it.

Daniel_K cannot re-enable anything that is dependent on HAL such as global DSP scheduling, hardware-mixed stream, per-source positioning, or hardware voices.

Likewise, neither can ALchemy + Creative drivers.

Here are some known pathways without any disagreements:

• Windows XP -> Game -> DS3D -> DSP hardware mixing -> EAX -> DAC
• Windows XP -> Game -> OpenAL -> DSP hardware mixing -> EAX -> DAC
• Windows XP -> Game -> OpenAL -> WaveOut -> DAC
• Windows Vista -> Game -> DS3D -> WASAPI -> DAC

What ALchemy makes possible is resurrect EAX (reverb, occlusion, filtering), but how it does that seems be causing disagreements:

• Windows Vista -> Game -> ALchemy -> OpenAL -> WASAPI -> EAX ?-> DAC
• Windows Vista -> Game -> ALchemy -> OpenAL -> EAX ?-> WASAPI -> DAC

An article on Steam shows that ALchemy enables EAX when there is no Sound Blaster installed, and that must mean EAX before WASAPI.
https://steamcommunity.com/sharedfiles/filede … /?id=2487107657

At least part of what Creative were doing is using their hardware as a key that unlocks software EAX on Vista.

[*]Windows Vista -> Game -> ALchemy -> OpenAL -> WASAPI -> EAX -> DAC

If you know a little audio programming then you can check that OpenAL has no dependency on WASAPI at all even on Vista+. You can use the same OpenAL router (OpenAL32.dll) and the same Creative hardware implementation (ct_oal.dll) on any systems (even on WinXP where WASAPI does not exist at all).
OpenAL predates Vista and Creative never wrote an OpenAL implementation that used WASAPI backend. If the OpenAL router does not find a hardware implementation library then it can use only Directsound3d hardware or Directsound3d software backend. Of course the Directsound3d hardware backend is not available on Vista+.

Moreover WASAPI has no EAX extension at all. The only Microsoft API that has EAX extension an thus can use EAX is Directsound 3d (hardware). So there is no such possible audio pipeline as 'OpenAL -> WASAPI -> EAX'...

Falcosoft wrote on 2026-01-14, 21:45:

[*]Windows Vista -> Game -> ALchemy -> OpenAL -> WASAPI -> EAX -> DAC

If you know a little audio programming then you can check that OpenAL has no dependency on WASAPI at all even on Vista+. You can use the same OpenAL router (OpenAL32.dll) and the same Creative hardware implementation (wrap_oal.dll) on any systems (even on WinXP where WASAPI does not exist at all).
OpenAL predates Vista and Creative never wrote an OpenAL implementation that used WASAPI backend. If the OpenAL router does not find a hardware implementation library then it can use only Directsound3d hardware or Directsound3d software backend. Of course the Directsound3d hardware backend is not available on Vista+.

OpenAL does not provide a backend, and OpenAL absolutely does have a dependency on there being a backend. That backend varies depending on the OS installed.

From OpenAL,

''This library is multi-platform, with support for Linux, Windows, Android, OS X, iOS, and more. Audio backends for PipeWire, PulseAudio, ALSA, WASAPI, OpenSL, CoreAudio, OSS, JACK, DirectSound, WinMM, Solaris, SoundIO, PortAudio, SDL2, SDL3, "Null" Output, and a .wav file writer are currently implemented.''

https://openal-soft.org/

Your screenshots show an Audigy enumerated, but does not show where mixing is done. Your WinXP GUI shows a choice between using Software or Hardware. Your Win10 GUI shows only Software - no Hardware available?!

MattRocks wrote on 2026-01-14, 22:05:

OpenAL does not provide a backend, and OpenAL absolutely does have a dependency on there being a backend. That backend varies de […]
Show full quote

Falcosoft wrote on 2026-01-14, 21:45:

[*]Windows Vista -> Game -> ALchemy -> OpenAL -> WASAPI -> EAX -> DAC

If you know a little audio programming then you can check that OpenAL has no dependency on WASAPI at all even on Vista+. You can use the same OpenAL router (OpenAL32.dll) and the same Creative hardware implementation (ct_oal.dll) on any systems (even on WinXP where WASAPI does not exist at all).
OpenAL predates Vista and Creative never wrote an OpenAL implementation that used WASAPI backend. If the OpenAL router does not find a hardware implementation library then it can use only Directsound3d hardware or Directsound3d software backend. Of course the Directsound3d hardware backend is not available on Vista+.

OpenAL does not provide a backend, and OpenAL absolutely does have a dependency on there being a backend. That backend varies depending on the OS installed.

From OpenAL,

''This library is multi-platform, with support for Linux, Windows, Android, OS X, iOS, and more. Audio backends for PipeWire, PulseAudio, ALSA, WASAPI, OpenSL, CoreAudio, OSS, JACK, DirectSound, WinMM, Solaris, SoundIO, PortAudio, SDL2, SDL3, "Null" Output, and a .wav file writer are currently implemented.''

https://openal-soft.org/

Your screenshots show devices enumerated on the PCI bus. It does not show where the mixing is done.

You cited from OpenL soft (soft_oal.dll) documentation that is an implementation of OpenAL the same way as ct_oal.dll.
if you install Creative's driver then it installs 3 components:
OpenAl32.dll the OpenAL router and wrap_oal.dll that DOES provide Directsound backend for non-Creative and pre-Audigy Creatrive cards.
For Audigy+ Creative cards the ct_oal.dll is also installed that provides native hardware accelaration.

For non-Crreative and pre-Audigy Creatrive cards the wrap_oal.dll provides 2 audio backends on Win XP :
1. Directsound 3d hardware (Generic hardware) that can also support EAX up to version 2.
2.Directsound 3d software (Generic software) that does not suppoort EAX and can only do stereo audio.

On Vista+ only 1 working backend exist provided by wrap_oal.dll that is Directsound 3d software (Generic software) .

So on modern (Vista+) Windows operating systems you need an alternative library like OpenAL Soft to get positional audio and EAX. soft_oal.dll works the same way as ct_oal.dll that is the OpenAL32.dll router enumerates it so it can be selected as a 'hardware' driver. Then it depends on the 'hardware' driver what additional API/library it uses be it WASAPI, Directsound etc.

Your screenshots show devices enumerated on the PCI bus. It does not show where the mixing is done.

You must be joking... What kind of device is 'OpenAL_Soft' on the PCI bus?
It's simply the soft_oal.dll library that is enumerated by the Openal32.dll router
'Generic software' and 'Generic hardware' are not PCI bus devices either but the Directsound 3d software and Directsound 3d hardware generic backends provided by wrap_oal.dll.

If you want I can send you test applications that can demonstarte for you how OpenAL architecture really works on Windows.

Falcosoft wrote on 2026-01-14, 22:23:

You cited from OpenL soft (soft_oal.dll) documentation that is an implementation of OpenAL the same way as wrap_oal.dll. if you […]
Show full quote

MattRocks wrote on 2026-01-14, 22:05:

OpenAL does not provide a backend, and OpenAL absolutely does have a dependency on there being a backend. That backend varies de […]
Show full quote

Falcosoft wrote on 2026-01-14, 21:45:

If you know a little audio programming then you can check that OpenAL has no dependency on WASAPI at all even on Vista+. You can use the same OpenAL router (OpenAL32.dll) and the same Creative hardware implementation (wrap_oal.dll) on any systems (even on WinXP where WASAPI does not exist at all).
OpenAL predates Vista and Creative never wrote an OpenAL implementation that used WASAPI backend. If the OpenAL router does not find a hardware implementation library then it can use only Directsound3d hardware or Directsound3d software backend. Of course the Directsound3d hardware backend is not available on Vista+.

OpenAL does not provide a backend, and OpenAL absolutely does have a dependency on there being a backend. That backend varies depending on the OS installed.

From OpenAL,

''This library is multi-platform, with support for Linux, Windows, Android, OS X, iOS, and more. Audio backends for PipeWire, PulseAudio, ALSA, WASAPI, OpenSL, CoreAudio, OSS, JACK, DirectSound, WinMM, Solaris, SoundIO, PortAudio, SDL2, SDL3, "Null" Output, and a .wav file writer are currently implemented.''

https://openal-soft.org/

Your screenshots show devices enumerated on the PCI bus. It does not show where the mixing is done.

You cited from OpenL soft (soft_oal.dll) documentation that is an implementation of OpenAL the same way as wrap_oal.dll.
if you install Creative's driver then it installs 2 components:
1. OpenAl32.dll - the OpenAL router that DOS provide Directsound backend for non-Crreative and pre-Audigy Creatrive cards.
2. For Audigy+ Creative cards the wrap_oal.dll is also installed that provides native hardware accelaration.

For on-Crreative and pre-Audigy Creatrive cards the OpenAL32.dll itself is enough since it provides 2 audio backends on XP :
1. Directsound 3d hardware (Generic hardware) that can also support EAX up to version.
2.Directsound 3d software (Generic software) that does not suppoort EAX and can only do stereo audio.

On Vista+ only 1 working backend exist provided by OpenAl32.dll itself that is .Directsound 3d software (Generic software) .

So on modern (Vista+) Windows operating systems you need an altearnative library liker OpenAL Soft to get positional audio and EAX. soft_oal.dll works the same way as wrap_oal.dll that is the OpenAL32.dll router enumerates it so it can be selected as a 'hardware' driver. Then it depends on the 'hardware' driver what additional API/library it uses be it WASAPI, Directsound etc.

Your screenshots show devices enumerated on the PCI bus. It does not show where the mixing is done.

You must be joking... What kind of device is 'OpenAL_Soft' on the PCI bus?
It's simply the soft_oal.dll library that is enumerated by the Openal32.dll router

If you want I can send you test applications that can demonstarte for you how OpenAL architecture really works on Windows.

I did not say exclusively devices on PCI bus. It shows other detected stuff too.

On all Windows versions the same implementation enumerates Creative devices and exposes extensions, but Vista+ policy prevents those implementations from feeding hardware mixing. That is why your Win10 correctly reports software-only mixing.

This is my working hypothesis. I'll ping you when I'm ready to do some testing!

I have an X-Fi Titanium HD THX (SB1270) so if I'm wrong, I'll be happy..

MattRocks wrote on 2026-01-14, 22:32:

I did not say exclusively devices on PCI bus. It shows other detected stuff too. […]
Show full quote

Falcosoft wrote on 2026-01-14, 22:23:

You cited from OpenL soft (soft_oal.dll) documentation that is an implementation of OpenAL the same way as wrap_oal.dll. if you […]
Show full quote

MattRocks wrote on 2026-01-14, 22:05:

OpenAL does not provide a backend, and OpenAL absolutely does have a dependency on there being a backend. That backend varies de […]
Show full quote

OpenAL does not provide a backend, and OpenAL absolutely does have a dependency on there being a backend. That backend varies depending on the OS installed.

From OpenAL,

''This library is multi-platform, with support for Linux, Windows, Android, OS X, iOS, and more. Audio backends for PipeWire, PulseAudio, ALSA, WASAPI, OpenSL, CoreAudio, OSS, JACK, DirectSound, WinMM, Solaris, SoundIO, PortAudio, SDL2, SDL3, "Null" Output, and a .wav file writer are currently implemented.''

https://openal-soft.org/

Your screenshots show devices enumerated on the PCI bus. It does not show where the mixing is done.

You cited from OpenL soft (soft_oal.dll) documentation that is an implementation of OpenAL the same way as wrap_oal.dll.
if you install Creative's driver then it installs 2 components:
1. OpenAl32.dll - the OpenAL router that DOS provide Directsound backend for non-Crreative and pre-Audigy Creatrive cards.
2. For Audigy+ Creative cards the wrap_oal.dll is also installed that provides native hardware accelaration.

For on-Crreative and pre-Audigy Creatrive cards the OpenAL32.dll itself is enough since it provides 2 audio backends on XP :
1. Directsound 3d hardware (Generic hardware) that can also support EAX up to version.
2.Directsound 3d software (Generic software) that does not suppoort EAX and can only do stereo audio.

On Vista+ only 1 working backend exist provided by OpenAl32.dll itself that is .Directsound 3d software (Generic software) .

So on modern (Vista+) Windows operating systems you need an altearnative library liker OpenAL Soft to get positional audio and EAX. soft_oal.dll works the same way as wrap_oal.dll that is the OpenAL32.dll router enumerates it so it can be selected as a 'hardware' driver. Then it depends on the 'hardware' driver what additional API/library it uses be it WASAPI, Directsound etc.

Your screenshots show devices enumerated on the PCI bus. It does not show where the mixing is done.

You must be joking... What kind of device is 'OpenAL_Soft' on the PCI bus?
It's simply the soft_oal.dll library that is enumerated by the Openal32.dll router

If you want I can send you test applications that can demonstarte for you how OpenAL architecture really works on Windows.

I did not say exclusively devices on PCI bus. It shows other detected stuff too.

On all Windows versions the same implementation enumerates Creative devices and exposes extensions, but Vista+ policy prevents those implementations from feeding hardware mixing. That is why your Win10 correctly reports software-only mixing.

This is my working hypothesis. I'll ping you when I'm ready to do some testing!

I have an X-Fi Titanium HD THX (SB1270) so if I'm wrong, I'll be happy..

Here is a proof that the available OpenAL backends have nothing to do with the PCI bus, If you remove ct_oal.dll and soft_oal.dll then you will only get this as available backends:

Some corrections regarding the above posts of mine: where I wrote wrap_oal.dll I meant ct_oal.dll. I remembered the name of the Creative hardware OpenAL implementation library wrongly.
@Edit:
I will fix my previous posts accordingly.

MattRocks wrote on 2026-01-14, 19:55:

An article on Steam shows that ALchemy enables EAX when there is no Sound Blaster installed, and that must mean EAX before WASAPI.
https://steamcommunity.com/sharedfiles/filede … /?id=2487107657

That's an unofficial hack of ALchemy. The official version only works on Creative cards.

That said, later Creative cards (post Titanium HD) don't have hardware EAX support. So if you're using one of those, ALchemy will indeed emulate EAX in software. I think this emulation might also be used by those cut down X-Fi Xtreme Audio cards, since they lack EAX hardware as well. Search this forum for sens_oal.dll versus ct_oal.dll and you'll get the idea.

Joseph_Joestar wrote on 2026-01-14, 22:48:

MattRocks wrote on 2026-01-14, 19:55:

An article on Steam shows that ALchemy enables EAX when there is no Sound Blaster installed, and that must mean EAX before WASAPI.
https://steamcommunity.com/sharedfiles/filede … /?id=2487107657

That's an unofficial hack of ALchemy. The official version only works on Creative cards.

That said, later Creative cards (post Titanium HD) don't have hardware EAX support. So if you're using one of those, ALchemy will indeed emulate EAX in software. I think this emulation might also be used by those cut down X-Fi Xtreme Audio cards, since they lack EAX hardware as well. Search this forum for sens_oal.dll versus ct_oal.dll and you'll get the idea.

It's hacked. But whether hacked or not, it's the same software. An un-hacked install is checking that a Creative card is installed.

Falcosoft wrote on 2026-01-14, 22:47:

Here is a proof that the available OpenAL backends have nothing to do with the PCI bus, If you remove ct_oal.dll and soft_oal.dl […]
Show full quote

MattRocks wrote on 2026-01-14, 22:32:

I did not say exclusively devices on PCI bus. It shows other detected stuff too. […]
Show full quote

Falcosoft wrote on 2026-01-14, 22:23:

You cited from OpenL soft (soft_oal.dll) documentation that is an implementation of OpenAL the same way as wrap_oal.dll. if you […]
Show full quote

You cited from OpenL soft (soft_oal.dll) documentation that is an implementation of OpenAL the same way as wrap_oal.dll.
if you install Creative's driver then it installs 2 components:
1. OpenAl32.dll - the OpenAL router that DOS provide Directsound backend for non-Crreative and pre-Audigy Creatrive cards.
2. For Audigy+ Creative cards the wrap_oal.dll is also installed that provides native hardware accelaration.

For on-Crreative and pre-Audigy Creatrive cards the OpenAL32.dll itself is enough since it provides 2 audio backends on XP :
1. Directsound 3d hardware (Generic hardware) that can also support EAX up to version.
2.Directsound 3d software (Generic software) that does not suppoort EAX and can only do stereo audio.

On Vista+ only 1 working backend exist provided by OpenAl32.dll itself that is .Directsound 3d software (Generic software) .

So on modern (Vista+) Windows operating systems you need an altearnative library liker OpenAL Soft to get positional audio and EAX. soft_oal.dll works the same way as wrap_oal.dll that is the OpenAL32.dll router enumerates it so it can be selected as a 'hardware' driver. Then it depends on the 'hardware' driver what additional API/library it uses be it WASAPI, Directsound etc.

You must be joking... What kind of device is 'OpenAL_Soft' on the PCI bus?
It's simply the soft_oal.dll library that is enumerated by the Openal32.dll router

If you want I can send you test applications that can demonstarte for you how OpenAL architecture really works on Windows.

I did not say exclusively devices on PCI bus. It shows other detected stuff too.

On all Windows versions the same implementation enumerates Creative devices and exposes extensions, but Vista+ policy prevents those implementations from feeding hardware mixing. That is why your Win10 correctly reports software-only mixing.

This is my working hypothesis. I'll ping you when I'm ready to do some testing!

I have an X-Fi Titanium HD THX (SB1270) so if I'm wrong, I'll be happy..

Here is a proof that the available OpenAL backends have nothing to do with the PCI bus, If you remove ct_oal.dll and soft_oal.dll then you will only get this as available backends:

The attachment win10_openal2.jpg is no longer available

Some corrections regarding the above posts of mine: where I wrote wrap_oal.dll I meant ct_oal.dll. I remembered the name of the Creative hardware OpenAL implementation library wrongly.
@Edit:
I will fix my previous posts accordingly.

That is not proof.

The claim is that ALchemy can route audio mixing to hardware or software.

Proof would be CPU benchmarking. With software mixing: CPU utilisation increases as voice count increases. With hardware mixing: CPU utilisation remains steady. But, CPUs are now so powerful that they barely register any stress when doing audio DSP functions, so the test needs to be careful. In principle, you should be able to crank up thousands of voices on software mixing and measure some kind of CPU increase. In principle the hardware would discard the extra voices (it's limited to 32/64/128) but discarding doesn't matter - what matters is that the CPU load doesn't follow the pattern of software mixing, because if it does then it's not mixing in hardware at all.

MattRocks wrote on 2026-01-15, 00:18:

That is not proof.

The claim is that ALchemy can route audio mixing to hardware or software...

And now you are talking about completely different things... Alchemy is not even mentioned so far in our conversation (it was logical since Alchemy is not needed at all by OpenAL software).
Previously you were talking about that
1. My screenshots show devices enumerated on the PCI bus.
2. Backend varies depending on the OS installed.
3. Vista+ policy prevents those implementations from feeding hardware mixing.
4. Win10 reports software-only mixing.

The proof proves that 1. and 2. are definitely wrong since available backends are enumerated according to the 3rd party available OpenAL drivers/implementations that are not part of the operating system.
Neither the OpenAL32.dll router nor the other *_oal.dll drivers are native part of any Windows versions.
3. is wrong since if you have a Creative Audigy/X-Fi card and ct_oal.dll installed (that is a library made by Creative) then you can use hardware mixing.
BTW, if your statement that Vista+ prevents implementations from doing all kinds of hardware mixing were true then hardware specific ASIO drivers could not work either. In reality both ASIO and OpenAl can access Audio hardware bypassing the Windows audio stack even on Vista+.
4, is wrong since if you have a Creative Audigy/X-Fi card and ct_oal.dll installed then software-only mixing is only one of the options (not even the default) and you have the hardware mixing option detected and implemented by by ct_oal.dll.
And in such cases hardware mixing option is also the default (not the software mixing).

But of course you can believe what you want. BTW, do you have any real experiences with Creative's Audigy/X-Fi cards and OpenAL software or only strong beliefs?

If you know the Win32 API somewhat then you must be aware that both Directsound and WASAPI uses COM interfaces and CoCreateinstance() calls to instantiate COM classes with fixed/known CLSIDs defined in Win32 headers.
If you use a static disassembler you can find the Directsound related COM calls in wrap_oal.dll but you will find absolutely no WASAPI related calls in ct_oal.dll.

And if you have a Creative Audigy+ card you can put the same OpenAL32.dll and ct_oal.dll files in the same folder as your OpenAL application and it will detect and use the same hardware mixing backends on WinXP, Vista, and Win 10.

yep...