Yeah, if I turn off CMSS 3D, then can't really tell if sound is coming from behind in DirectSound3D / OpenAL games with headphones.

To my ears at least, it seems their 3D effect in Sens_oal.dll sounds better. But that implementation has other oddities, EAX reverb may be too pronounced, The Suffering for instance, that doesn't even use EAX, sounds reverby all the time, when I launch Mafia 1, the sound when profile menu shows up, is reverby. It's just weird.

Perhaps long term, the future is in OpenAL Soft. Creative may as well be considered dead as a company at this point. I've read of people having problems with their X-Fi drivers and just giving up on them on Win10 machines. As for my experience with Audigy RX, it's easy to get the driver to bring the OS down, can't unload the damn thing without BSOD. Doesn't matter if it's Windows XP or 11...

Just exercising its OpenAL a bit with MetaAudio plugin (Half-Life) kills EAX permanently until reboot. I mentioned Amnesia: The Dark Descent before. It's a buggy fragile mess. Their legacy cards may as well be considered a paperweight with no future. Or you think someone will come up with full-featured drivers that don't suck? Given the obscurity of these cards alone, it seems unlikely.

SansPlomb95 wrote on 2026-01-21, 19:25:

MattRocks wrote on 2026-01-15, 15:20:

Sadly, due to having only Vista+ drivers, my X-Fi Titanium HD THX is a beautiful lemon - an anomaly that existed only for the small number of users who didn't see Microsoft's trap.

I believe there is a working custom WinXP driver from DanielK for the Titanium HD, this card still uses an E-MU 20K2 chip after all.
I might have tried it myself two years ago but I completely forgot the outcome, I think it worked as expected.

I would be very interested to know if anybody here has successfully installed drivers for Titanium Hd in Windows Xp. The only thing that is certain is that in Daniel K' latest support pack there is a footnote saying that Titanium Hd is not supported in Windows Xp, on the other hand in previous packs by him that footnote is omitted. That has led some to believe that his older drivers might support the T-Hd in Xp, but from my search through various forums i have yet to find someone to confirm this, in fact in think i have stumbled upon a couple of cases where it was supposedly confirmed that it doesn't work in Xp.

SansPlomb95 wrote on 2026-01-21, 19:33:

Project Acoustics now called Triton is alive and well. Microsoft decided to jealously keep the technology for their own first party studios instead.

Actually, the project was originally called Triton and I don't see any new games with this technology.

Its main drawback is the high cost of baking waves. Depending on mesh complexity, a single small scene would require several days of calculations on 8-core CPU.
It's a shame the project didn't survive until the AI ​​boom, they probably would have significantly reduced the baking time by training the models.

ott wrote on 2026-01-22, 08:00:

Actually, the project was originally called Triton and I don't see any new games with this technology. […]
Show full quote

SansPlomb95 wrote on 2026-01-21, 19:33:

Project Acoustics now called Triton is alive and well. Microsoft decided to jealously keep the technology for their own first party studios instead.

Actually, the project was originally called Triton and I don't see any new games with this technology.

Its main drawback is the high cost of baking waves. Depending on mesh complexity, a single small scene would require several days of calculations on 8-core CPU.
It's a shame the project didn't survive until the AI ​​boom, they probably would have significantly reduced the baking time by training the models.

The latest project to date shipping with the Triton engine was no less than Call of Duty Black Ops 7 released this last November as confirmed by the creator and still head of the Triton team https://www.linkedin.com/feed/update/urn:li:a … 42477367177216/

It was also used in a Black Ops 6 update and in Hellblade II, all Microsoft owned titles.

SansPlomb95 wrote on 2026-01-22, 08:22:

The latest project to date shipping with the Triton engine was no less than Call of Duty Black Ops 7 released this last November as confirmed by the creator and still head of the Triton team https://www.linkedin.com/feed/update/urn:li:a … 42477367177216/

It was also used in a Black Ops 6 update and in Hellblade II, all Microsoft owned titles.

I'm glad to hear that!
Thanks for the game list, I'll definitely try to play them.

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

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..

Hi,
I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Windows 10. I think this is a more obvious demonstration/proof than the previous one.
What you can see:
1. When you have a Creative Audigy/X-Fi card and ct_oal.dll is also installed then the default driver is a hardware driver that bypasses the Windows audio stack/mixer. When the HW driver is selected the application that uses this audio path is not even enumerated by the Windows mixer app.
2. When the fallback 'Generic Software' driver is selected then the application that uses this software fallback audio path is enumerated by the Windows mixer app properly, and you can use the software mixer to change the audio volume.
3. When the hardware driver is selected again then the application is not removed from the Windows mixer app, but you are unable to change the volume by the Windows mixer app.

https://youtu.be/oUCYy-MY418

@Edit:
I also attach my test application so anyone can confirm my results:

Falcosoft wrote on 2026-01-23, 17:50:

Hi, I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Wi […]
Show full quote

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

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..

Hi,
I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Windows 10. I think this is a more obvious demonstration/proof than the previous one.
What you can see:
1. When you have a Creative Audigy/X-Fi card and ct_oal.dll is also installed then the default driver is a hardware driver that bypasses the Windows audio stack/mixer. When the HW driver is selected the application that uses this audio path is not even enumerated by the Windows mixer app.
2. When the fallback 'Generic Software' driver is selected then the application that uses this software fallback audio path is enumerated by the Windows mixer app properly, and you can use the software mixer to change the audio volume.
3. When the hardware driver is selected again then the application is not removed from the Windows mixer app, but you are unable to change the volume by the Windows mixer app.

https://youtu.be/oUCYy-MY418

@Edit:
I also attach my test application so anyone can confirm my results:

The attachment OpenAlTest.zip is no longer available

I do appreciate the test, and you have shown that OpenAL bypasses the Windows mixer. But..

The problem is nobody can observe where the drivers are sending the mixing workload. I can see it is not sending it to the Windows mixer, but it could still be software mixing:

• What happens when you select OpenAL soft (has no hardware mixer) and run the test? Does Windows mixer get bypassed?
• If someone has a Sound Blaster Z (has no hardware mixer) and runs the same test, what happens? Does Windows mixer get bypassed?

If Audigy result is different to OpenAL soft, and Audigy is different to SB Z, then my view is you have proven hardware mixing. But, if one of the others also bypasses the Windows mixer then the mixing location remains inconclusive.

MattRocks wrote on 2026-01-23, 21:58:

I do appreciate the test, and you have shown that OpenAL bypasses the Windows mixer. But.. […]
Show full quote

Falcosoft wrote on 2026-01-23, 17:50:

Hi, I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Wi […]
Show full quote

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

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..

Hi,
I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Windows 10. I think this is a more obvious demonstration/proof than the previous one.
What you can see:
1. When you have a Creative Audigy/X-Fi card and ct_oal.dll is also installed then the default driver is a hardware driver that bypasses the Windows audio stack/mixer. When the HW driver is selected the application that uses this audio path is not even enumerated by the Windows mixer app.
2. When the fallback 'Generic Software' driver is selected then the application that uses this software fallback audio path is enumerated by the Windows mixer app properly, and you can use the software mixer to change the audio volume.
3. When the hardware driver is selected again then the application is not removed from the Windows mixer app, but you are unable to change the volume by the Windows mixer app.

https://youtu.be/oUCYy-MY418

@Edit:
I also attach my test application so anyone can confirm my results:

The attachment OpenAlTest.zip is no longer available

I do appreciate the test, and you have shown that OpenAL bypasses the Windows mixer. But..

The problem is nobody can observe where the drivers are sending the mixing workload. I can see it is not sending it to the Windows mixer, but it could still be software mixing:

• What happens when you select OpenAL soft (has no hardware mixer) and run the test? Does Windows mixer get bypassed?
• If someone has a Sound Blaster Z (has no hardware mixer) and runs the same test, what happens? Does Windows mixer get bypassed?

If Audigy result is different to OpenAL soft, and Audigy is different to SB Z, then my view is you have proven hardware mixing. But, if one of the others also bypasses the Windows mixer then the mixing location remains inconclusive.

Hi,
Unfortunatley I have no Sound Blaster Z so I cannot test it, but my Audigy with the OpenAL Soft driver does NOT bypass the Windows audio stack/software mixer. Here is my 2nd test video about this:
https://youtu.be/hROI1oiMiQk

Falcosoft wrote on 2026-01-23, 17:50:

I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Windows 10. I think this is a more obvious demonstration/proof than the previous one.

Thanks for the demo! Similar to hardware ASIO behavior, it also bypasses the Windows mixer.

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

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

Hi, Unfortunatley I have no Sound Blaster Z so I cannot test it, but my Audigy with the OpenAL Soft driver does NOT bypass the W […]
Show full quote

MattRocks wrote on 2026-01-23, 21:58:

I do appreciate the test, and you have shown that OpenAL bypasses the Windows mixer. But.. […]
Show full quote

Falcosoft wrote on 2026-01-23, 17:50:

Hi, I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Wi […]
Show full quote

Hi,
I have made a video that shows how Creative's HW OpenAL implementation bypasses the Windows audio stack/software mixer on Windows 10. I think this is a more obvious demonstration/proof than the previous one.
What you can see:
1. When you have a Creative Audigy/X-Fi card and ct_oal.dll is also installed then the default driver is a hardware driver that bypasses the Windows audio stack/mixer. When the HW driver is selected the application that uses this audio path is not even enumerated by the Windows mixer app.
2. When the fallback 'Generic Software' driver is selected then the application that uses this software fallback audio path is enumerated by the Windows mixer app properly, and you can use the software mixer to change the audio volume.
3. When the hardware driver is selected again then the application is not removed from the Windows mixer app, but you are unable to change the volume by the Windows mixer app.

https://youtu.be/oUCYy-MY418

@Edit:
I also attach my test application so anyone can confirm my results:

The attachment OpenAlTest.zip is no longer available

I do appreciate the test, and you have shown that OpenAL bypasses the Windows mixer. But..

The problem is nobody can observe where the drivers are sending the mixing workload. I can see it is not sending it to the Windows mixer, but it could still be software mixing:

• What happens when you select OpenAL soft (has no hardware mixer) and run the test? Does Windows mixer get bypassed?
• If someone has a Sound Blaster Z (has no hardware mixer) and runs the same test, what happens? Does Windows mixer get bypassed?

If Audigy result is different to OpenAL soft, and Audigy is different to SB Z, then my view is you have proven hardware mixing. But, if one of the others also bypasses the Windows mixer then the mixing location remains inconclusive.

Hi,
Unfortunatley I have no Sound Blaster Z so I cannot test it, but my Audigy with the OpenAL Soft driver does NOT bypass the Windows audio stack/software mixer. Here is my 2nd test video about this:
https://youtu.be/hROI1oiMiQk

Accepted. You are showing a user-mode (OpenAL) binary calling a kernel-mode (Creative driver) binary. That is the NT5 pathway on NT6, and that is what Creative Labs claimed. That pathway can be established, but is it stable?

Frustration: It's in the history of Creative Labs.

• Creative did demonstrate it
• Creative did ship it
• Creative could not guarantee it
• Creative abandoned it

Warning: You are going to get frustrated with me for pointing this out.

The NT5 pathway (and Creative’s NT6 OpenAL path) assume the audio endpoint is left alone, because NT5 sets up each endpoint once only. And, NT5 will BSOD if an endpoint stops responding. Solving BSOD is why NT6 actively resets endpoints.

Example: I had a low power late-WinXP HP laptop (also sold as a chromebook) but XP is insecure. I installed Win7 and established Wi-Fi connections, and then the system randomly dropped connections. I blamed drivers. Investigations were inconclusive despite other owners reporting the same. The "fault" was more likely NT6 actively reseting the endpoint, possibly power cycling, and I never isolated the trigger because I can't see kernel-mode events. I gave up out of frustration, but not before deleting the XP recovery partition. BSOD would have been better because it would have surfaced clearer diagnostics.

Back to EAX: My concern is, will NT6 reset an Audigy endpoint while OpenAL is calling it? That is a really frustrating question to ask because it is true to NT6 behaviour, it's unobservable kernel-mode stuff, and there is a long history of anecdotal complaints suggesting it happens without anyone really pinning down why. The most extreme outcomes might resemble,

" I have a X-fi Titanium HD and about a week and a half ago when the anti-cheat got updated, my audio started completely cutting out a few minutes into a game ... other audio devices work, but I have to reboot the PC to get the X-fi card to work again." - EA Forums

https://forums.ea.com/discussions/battlefield … o-card/12027397

MattRocks wrote on 2026-01-24, 05:06:

Accepted. You are showing a user-mode (OpenAL) binary calling a kernel-mode (Creative driver) binary. That is the NT5 pathway o […]
Show full quote

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

Hi, Unfortunatley I have no Sound Blaster Z so I cannot test it, but my Audigy with the OpenAL Soft driver does NOT bypass the W […]
Show full quote

MattRocks wrote on 2026-01-23, 21:58:

I do appreciate the test, and you have shown that OpenAL bypasses the Windows mixer. But.. […]
Show full quote

I do appreciate the test, and you have shown that OpenAL bypasses the Windows mixer. But..

The problem is nobody can observe where the drivers are sending the mixing workload. I can see it is not sending it to the Windows mixer, but it could still be software mixing:

• What happens when you select OpenAL soft (has no hardware mixer) and run the test? Does Windows mixer get bypassed?
• If someone has a Sound Blaster Z (has no hardware mixer) and runs the same test, what happens? Does Windows mixer get bypassed?

If Audigy result is different to OpenAL soft, and Audigy is different to SB Z, then my view is you have proven hardware mixing. But, if one of the others also bypasses the Windows mixer then the mixing location remains inconclusive.

Hi,
Unfortunatley I have no Sound Blaster Z so I cannot test it, but my Audigy with the OpenAL Soft driver does NOT bypass the Windows audio stack/software mixer. Here is my 2nd test video about this:
https://youtu.be/hROI1oiMiQk

Accepted. You are showing a user-mode (OpenAL) binary calling a kernel-mode (Creative driver) binary. That is the NT5 pathway on NT6, and that is what Creative Labs claimed. That pathway can be established, but is it stable?

Frustration: It's in the history of Creative Labs.

• Creative did demonstrate it
• Creative did ship it
• Creative could not guarantee it
• Creative abandoned it

Warning: You are going to get frustrated with me for pointing this out.

The NT5 pathway (and Creative’s NT6 OpenAL path) assume the audio endpoint is left alone, because NT5 sets up each endpoint once only. And, NT5 will BSOD if an endpoint stops responding. Solving BSOD is why NT6 actively resets endpoints.

Example: I had a low power late-WinXP HP laptop (also sold as a chromebook) but XP is insecure. I installed Win7 and established Wi-Fi connections, and then the system randomly dropped connections. I blamed drivers. Investigations were inconclusive despite other owners reporting the same. The "fault" was more likely NT6 actively reseting the endpoint, possibly power cycling, and I never isolated the trigger because I can't see kernel-mode events. I gave up out of frustration, but not before deleting the XP recovery partition. BSOD would have been better because it would have surfaced clearer diagnostics.

Back to EAX: My concern is, will NT6 reset an Audigy endpoint while OpenAL is calling it? That is a really frustrating question to ask because it is true to NT6 behaviour, it's unobservable kernel-mode stuff, and there is a long history of anecdotal complaints suggesting it happens without anyone really pinning down why. The most extreme outcomes might resemble,

" I have a X-fi Titanium HD and about a week and a half ago when the anti-cheat got updated, my audio started completely cutting out a few minutes into a game ... other audio devices work, but I have to reboot the PC to get the X-fi card to work again." - EA Forums

https://forums.ea.com/discussions/battlefield … o-card/12027397

I do not have an X-fi so I cannot confirm/refute its problems. But I have 2 Windows 10 systems (both installed about in 2017) with Audigy/Audigy 2 ZS and OpenAL (as well as ASIO) is absolutely stable. The only use case that caused problems/BSODs with my Audigy/Audigy 2 ZS is the hardware SF2 MIDI synth. If I use both MIDI Out ports A and B and sending relatively large amount of Midi messages to both ports then I consistently run into BSODs.
BTW, I'm using the last but one DanielK Audigy driver pack on both systems.

Falcosoft wrote on 2026-01-24, 07:22:

MattRocks wrote on 2026-01-24, 05:06:

Accepted. You are showing a user-mode (OpenAL) binary calling a kernel-mode (Creative driver) binary. That is the NT5 pathway o […]
Show full quote

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

Hi,
Unfortunatley I have no Sound Blaster Z so I cannot test it, but my Audigy with the OpenAL Soft driver does NOT bypass the Windows audio stack/software mixer. Here is my 2nd test video about this:
https://youtu.be/hROI1oiMiQk

Accepted. You are showing a user-mode (OpenAL) binary calling a kernel-mode (Creative driver) binary. That is the NT5 pathway on NT6, and that is what Creative Labs claimed. That pathway can be established, but is it stable?

Frustration: It's in the history of Creative Labs.

• Creative did demonstrate it
• Creative did ship it
• Creative could not guarantee it
• Creative abandoned it

Warning: You are going to get frustrated with me for pointing this out.

The NT5 pathway (and Creative’s NT6 OpenAL path) assume the audio endpoint is left alone, because NT5 sets up each endpoint once only. And, NT5 will BSOD if an endpoint stops responding. Solving BSOD is why NT6 actively resets endpoints.

Example: I had a low power late-WinXP HP laptop (also sold as a chromebook) but XP is insecure. I installed Win7 and established Wi-Fi connections, and then the system randomly dropped connections. I blamed drivers. Investigations were inconclusive despite other owners reporting the same. The "fault" was more likely NT6 actively reseting the endpoint, possibly power cycling, and I never isolated the trigger because I can't see kernel-mode events. I gave up out of frustration, but not before deleting the XP recovery partition. BSOD would have been better because it would have surfaced clearer diagnostics.

Back to EAX: My concern is, will NT6 reset an Audigy endpoint while OpenAL is calling it? That is a really frustrating question to ask because it is true to NT6 behaviour, it's unobservable kernel-mode stuff, and there is a long history of anecdotal complaints suggesting it happens without anyone really pinning down why. The most extreme outcomes might resemble,

" I have a X-fi Titanium HD and about a week and a half ago when the anti-cheat got updated, my audio started completely cutting out a few minutes into a game ... other audio devices work, but I have to reboot the PC to get the X-fi card to work again." - EA Forums

https://forums.ea.com/discussions/battlefield … o-card/12027397

I do not have an X-fi so I cannot confirm/refute its problems. But I have 2 Windows 10 systems (both installed about in 2017) with Audigy/Audigy 2 ZS and OpenAL (as well as ASIO) is absolutely stable. The only use case that caused problems/BSODs with my Audigy/Audigy 2 ZS is the hardware SF2 MIDI synth. If I use both MIDI Out ports A and B and sending relatively large amount of Midi messages to both ports then I consistently run into BSODs.
BTW, I'm using the last but one DanielK Audigy driver pack on both systems.

I’m not disputing that OpenAL itself is stable. The disagreement isn’t about OpenAL.

The uncertainty is whether "hardware mixing" is always stable. There’s no reliable way to prove that because Creative drivers and/or OpenAL can silently fall back to software paths if a hardware path throws an exception. Games, OpenAL, and anything else operating in user-mode would not know what has happened in kernel-mode.

That means two people can both be right at the same time: one feels the audio is wrong, another feels it’s correct. Neither can prove it scientifically, but there are many anecdotes from owners who felt uneasy or suspicious about what they heard.

Your results give me hope that my Titanium HD, on a clean and well-behaved Windows 10 system, probably will hardware-mix because you are confident and it matches what Creative initially claimed. But on a stressed or messy system, it’s impossible to know whether a low-level fault causes a silent fallback to software mixing.

In the end, only Creative is well placed to assess the concern definitively using their hardware debugging tools. We must assume Creative did extensive testing. And, we know Creative abandoned hardware mixing without giving a public explanation. Daniel K couldn’t prove what was happening due to limited resources, and Creative’s legal response effectively closed that avenue.

In summary, I am not disputing your findings and I value the insights you are adding. I'm just not ready to draw a conclusion. One possible test would be to compare how OpenAL software mixing sounds versus Audigy hardware mixing on your system, then stress the system and see if the differences persist. If they always sound identical, perhaps a computational comparison of the outputs could reveal subtle differences.

MattRocks wrote on 2026-01-24, 19:21:

I’m not disputing that OpenAL itself is stable. The disagreement isn’t about OpenAL. […]
Show full quote

I’m not disputing that OpenAL itself is stable. The disagreement isn’t about OpenAL.

The uncertainty is whether "hardware mixing" is always stable. There’s no reliable way to prove that because Creative drivers and/or OpenAL can silently fall back to software paths if a hardware path throws an exception. Games, OpenAL, and anything else operating in user-mode would not know what has happened in kernel-mode.
...

In summary, I am not disputing your findings and I value the insights you are adding. I'm also stopping short of drawing a conclusion. On your system, does OpenAL software mixing sound different to Audigy hardware mixing?

Hi,
Such kind of automatic fallback to the software path is not possible even in theory. An opened OpenAL context is tied to the driver implementation from start to end. The software fallback is implemented by a completely different driver (wrap_oal.dll).
Even the feature set is completely different and yes, they also sound completely differently. The software fallback driver does not support real 3D positional audio and it only supports EAX 2 maximum. The EAX reverb implementation in the software driver is minimal and sounds horrible.
So If the hardware driver fails there is no way to silently continue with a different software emulation. In case of an unhandled HW driver exception in the best case your application crashes but in the worst case you will get a BSOD.

Falcosoft wrote on 2026-01-24, 19:52:

Hi, Such kind of automatic fallback to the software path is not possible even in theory. An opened OpenAL context is tied to the […]
Show full quote

MattRocks wrote on 2026-01-24, 19:21:

I’m not disputing that OpenAL itself is stable. The disagreement isn’t about OpenAL. […]
Show full quote

I’m not disputing that OpenAL itself is stable. The disagreement isn’t about OpenAL.

The uncertainty is whether "hardware mixing" is always stable. There’s no reliable way to prove that because Creative drivers and/or OpenAL can silently fall back to software paths if a hardware path throws an exception. Games, OpenAL, and anything else operating in user-mode would not know what has happened in kernel-mode.
...

In summary, I am not disputing your findings and I value the insights you are adding. I'm also stopping short of drawing a conclusion. On your system, does OpenAL software mixing sound different to Audigy hardware mixing?

Hi,
Such kind of automatic fallback to the software path is not possible even in theory. An opened OpenAL context is tied to the driver implementation from start to end. The software fallback is implemented by a completely different driver (wrap_oal.dll).
Even the feature set is completely different and yes, they also sound completely differently. The software fallback driver does not support real 3D positional audio and it only supports EAX 2 maximum. The EAX reverb implementation in the software driver is minimal and sounds horrible.
So If the hardware driver fails there is no way to silently continue with a different software emulation. In case of an unhandled HW driver exception in the best case your application crashes but in the worst case you will get a BSOD.

OpenAL does not talk directly with any hardware. Instead, it talks to a kernel-mode driver.

I'm naming two cards only only because a Reddit post explicitly names them:

Correct me I'm wrong but my understanding is that the Ae5-Plus has only a "software DSP" in Creative's kernel-mode drivers (cthda.sys). In contrast, Titanium HD has both "software DSP" (cthda.sys) and "hardware DSP" (ha20x2k.sys) in Creative's kernel-mode drivers. Here's a complaint about migrating from Titanium HD to Ae5-Plus:

https://www.reddit.com/r/SoundBlasterOfficial … l_and_fun_with/

That user's post is about their difficulties establishing an OpenAL connection after migrating. They then succeeded in connecting OpenAL to the Ae5-Plus kernel-mode drivers. And, they didn't complain about any change in EAX audio quality.

My point is that user-mode OpenAL is blind to whether the connected kernel-mode Creative driver is executing a "software path" or "hardware path." Furthermore, the listeners seemed oblivious when the "hardware path" was removed.

We know the Titanium HD has a hardware path option. But, we can't know that the hardware path option is being exercised unless we can detect a hardware signature in the analogue output. I assume it's the same for an Audigy? And, when a "hardware path" exists - why ship a "software path" at all?

MattRocks wrote on 2026-01-25, 00:20:

OpenAL does not talk directly with any hardware. Instead, it talks to a kernel-mode driver. […]
Show full quote

Falcosoft wrote on 2026-01-24, 19:52:

Hi, Such kind of automatic fallback to the software path is not possible even in theory. An opened OpenAL context is tied to the […]
Show full quote

MattRocks wrote on 2026-01-24, 19:21:

I’m not disputing that OpenAL itself is stable. The disagreement isn’t about OpenAL. […]
Show full quote

I’m not disputing that OpenAL itself is stable. The disagreement isn’t about OpenAL.

The uncertainty is whether "hardware mixing" is always stable. There’s no reliable way to prove that because Creative drivers and/or OpenAL can silently fall back to software paths if a hardware path throws an exception. Games, OpenAL, and anything else operating in user-mode would not know what has happened in kernel-mode.
...

In summary, I am not disputing your findings and I value the insights you are adding. I'm also stopping short of drawing a conclusion. On your system, does OpenAL software mixing sound different to Audigy hardware mixing?

Hi,
Such kind of automatic fallback to the software path is not possible even in theory. An opened OpenAL context is tied to the driver implementation from start to end. The software fallback is implemented by a completely different driver (wrap_oal.dll).
Even the feature set is completely different and yes, they also sound completely differently. The software fallback driver does not support real 3D positional audio and it only supports EAX 2 maximum. The EAX reverb implementation in the software driver is minimal and sounds horrible.
So If the hardware driver fails there is no way to silently continue with a different software emulation. In case of an unhandled HW driver exception in the best case your application crashes but in the worst case you will get a BSOD.

OpenAL does not talk directly with any hardware. Instead, it talks to a kernel-mode driver.

I'm naming two cards only only because a Reddit post explicitly names them:

Correct me I'm wrong but my understanding is that the Ae5-Plus has only a "software DSP" in Creative's kernel-mode drivers (cthda.sys). In contrast, Titanium HD has both "software DSP" (cthda.sys) and "hardware DSP" (ha20x2k.sys) in Creative's kernel-mode drivers. Here's a complaint about migrating from Titanium HD to Ae5-Plus:

https://www.reddit.com/r/SoundBlasterOfficial … l_and_fun_with/

That user's post is about their difficulties establishing an OpenAL connection after migrating. They then succeeded in connecting OpenAL to the Ae5-Plus kernel-mode drivers. And, they didn't complain about any change in EAX audio quality.

My point is that user-mode OpenAL is blind to whether the connected kernel-mode Creative driver is executing a "software path" or "hardware path." Furthermore, the listeners seemed oblivious when the "hardware path" was removed.

We know the Titanium HD has a hardware path option. But, we can't know that the hardware path option is being exercised unless we can detect a hardware signature in the analogue output. I assume it's the same for an Audigy? And, when a "hardware path" exists - why ship a "software path" at all?

Hi,
OIpenAL architecture works the following way by default: The application only has direct dependency on the OpenAL router (OpenAL32.dll). The router enumerates the real driver implementations and ranks them according to feature sets etc. (HW implementations have a higher priority). Then the router redirects the application calls either to the default driver or to the one that has been explicitly specified by the application.
Most OpenAL games/software relies on the router to select a default driver and do not specify an explicit driver name to use.
Usually this is why it's problematic to determine what driver is actually used by the application.

But knowing the OpenAL architecture can help making sure that you use only the driver implementation that you want to test/use. That is:
The default OpenAL router (OpenAL32.dll) is actually optional. You can always rename a specific hardware/software driver implementation to OpenAL32.dll and copy it to the application's folder. In this case there is no router to redirect calls and the application calls the exports of the specific driver directly. This way you can make sure that no other alternative driver or software callback is involved.
In practice this means that e.g. if you rename ct_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then only the Audigy/X-fi HW driver is used.
In this case you can also experience that the application can only work with Audigy/X-fi cards. For all other cards you will get an initialization error, no software fallback is available.

On the other hand if you rename wrap_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then always the fallback is used even in case of Audigy/X-fi cards.

BTW, the first software fallback driver (wrap_oal.dll) by Creative was part of the OpenAL redistributable (oalinst.exe) since the earliest days of OpenAL. This driver was written by Creative originally for all other cards that do not have direct HW implementations. But of course it can even work with cards that do have HW implementations.

The sens_oal.dll driver is similar to soft_oal.dll driver in the sense that it provides full 3d positional audio and EAX implementation without relying on specific hardware features. It's a software only driver for post X-fi Creative cards.

Falcosoft wrote on 2026-01-25, 10:55:

Hi, OIpenAL architecture works the following way by default: The application only has direct dependency on the OpenAL router (Op […]
Show full quote

MattRocks wrote on 2026-01-25, 00:20:

OpenAL does not talk directly with any hardware. Instead, it talks to a kernel-mode driver. […]
Show full quote

Falcosoft wrote on 2026-01-24, 19:52:

Hi, Such kind of automatic fallback to the software path is not possible even in theory. An opened OpenAL context is tied to the […]
Show full quote

Hi,
Such kind of automatic fallback to the software path is not possible even in theory. An opened OpenAL context is tied to the driver implementation from start to end. The software fallback is implemented by a completely different driver (wrap_oal.dll).
Even the feature set is completely different and yes, they also sound completely differently. The software fallback driver does not support real 3D positional audio and it only supports EAX 2 maximum. The EAX reverb implementation in the software driver is minimal and sounds horrible.
So If the hardware driver fails there is no way to silently continue with a different software emulation. In case of an unhandled HW driver exception in the best case your application crashes but in the worst case you will get a BSOD.

OpenAL does not talk directly with any hardware. Instead, it talks to a kernel-mode driver.

I'm naming two cards only only because a Reddit post explicitly names them:

Correct me I'm wrong but my understanding is that the Ae5-Plus has only a "software DSP" in Creative's kernel-mode drivers (cthda.sys). In contrast, Titanium HD has both "software DSP" (cthda.sys) and "hardware DSP" (ha20x2k.sys) in Creative's kernel-mode drivers. Here's a complaint about migrating from Titanium HD to Ae5-Plus:

https://www.reddit.com/r/SoundBlasterOfficial … l_and_fun_with/

That user's post is about their difficulties establishing an OpenAL connection after migrating. They then succeeded in connecting OpenAL to the Ae5-Plus kernel-mode drivers. And, they didn't complain about any change in EAX audio quality.

My point is that user-mode OpenAL is blind to whether the connected kernel-mode Creative driver is executing a "software path" or "hardware path." Furthermore, the listeners seemed oblivious when the "hardware path" was removed.

We know the Titanium HD has a hardware path option. But, we can't know that the hardware path option is being exercised unless we can detect a hardware signature in the analogue output. I assume it's the same for an Audigy? And, when a "hardware path" exists - why ship a "software path" at all?

Hi,
OIpenAL architecture works the following way by default: The application only has direct dependency on the OpenAL router (OpenAL32.dll). The router enumerates the real driver implementations and ranks them according to feature sets etc. (HW implementations have a higher priority). Then the router redirects the application calls either to the default driver or to the one that has been explicitly specified by the application.
Most OpenAL games/software relies on the router to select a default driver and do not specify an explicit driver name to use.
Usually this is why it's problematic to determine what driver is actually used by the application.

But knowing the OpenAL architecture can help making sure that you use only the driver implementation that you want to test/use. That is:
The default OpenAL router (OpenAL32.dll) is actually optional. You can always rename a specific hardware/software driver implementation to OpenAL32.dll and copy it to the application's folder. In this case there is no router to redirect calls and the application calls the exports of the specific driver directly. This way you can make sure that no other alternative driver or software callback is involved.
In practice this means that e.g. if you rename ct_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then only the Audigy/X-fi HW driver is used.
In this case you can also experience that the application can only work with Audigy/X-fi cards. For all other cards you will get an initialization error, no software fallback is available.

The attachment direct_hw_openal.png is no longer available

On the other hand if you rename wrap_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then always the fallback is used even in case of Audigy/X-fi cards.

The attachment fallback_sw_openal.png is no longer available

BTW, the first software fallback driver (wrap_oal.dll) by Creative was part of the OpenAL redistributable (oalinst.exe) since the earliest days of OpenAL. This driver was written by Creative originally for all other cards that do not have direct HW implementations. But of course it can even work with cards that do have HW implementations.

The sens_oal.dll driver is similar to soft_oal.dll driver in the sense that it provides full 3d positional audio and EAX implementation without relying on specific hardware features. It's a software only driver for post X-fi Creative cards.

No dispute on OpenAL mechanics. But, OpenAL does not communicate directly with silicone. And, the ct_oal.dll is what ultimately decides whether a soft/hard DSP is exercised.

You are describing the top part of the diagram and ignoring the bottom part of the same diagram:

1OpenAL  -  ct_oal.dll  
2                        ├─ hardware DSP path (ha20x2k.sys)
3                        └─ software DSP path (cthda.sys)

Renaming the file doesn't change the pathways:

1OpenAL  - openal32.dll  
2                         ├─ hardware DSP path (ha20x2k.sys)
3                         └─ software DSP path (cthda.sys)

My understanding is that Creative provided a software path for hardware silicone because they knew NT6 periodically resets states in silicone.

MattRocks wrote on 2026-01-25, 12:52:

No dispute on OpenAL mechanics. But, OpenAL does not communicate directly with silicone. And, the ct_oal.dll is what ultimately […]
Show full quote

Falcosoft wrote on 2026-01-25, 10:55:

Hi, OIpenAL architecture works the following way by default: The application only has direct dependency on the OpenAL router (Op […]
Show full quote

MattRocks wrote on 2026-01-25, 00:20:

OpenAL does not talk directly with any hardware. Instead, it talks to a kernel-mode driver. […]
Show full quote

OpenAL does not talk directly with any hardware. Instead, it talks to a kernel-mode driver.

I'm naming two cards only only because a Reddit post explicitly names them:

Correct me I'm wrong but my understanding is that the Ae5-Plus has only a "software DSP" in Creative's kernel-mode drivers (cthda.sys). In contrast, Titanium HD has both "software DSP" (cthda.sys) and "hardware DSP" (ha20x2k.sys) in Creative's kernel-mode drivers. Here's a complaint about migrating from Titanium HD to Ae5-Plus:

https://www.reddit.com/r/SoundBlasterOfficial … l_and_fun_with/

That user's post is about their difficulties establishing an OpenAL connection after migrating. They then succeeded in connecting OpenAL to the Ae5-Plus kernel-mode drivers. And, they didn't complain about any change in EAX audio quality.

My point is that user-mode OpenAL is blind to whether the connected kernel-mode Creative driver is executing a "software path" or "hardware path." Furthermore, the listeners seemed oblivious when the "hardware path" was removed.

We know the Titanium HD has a hardware path option. But, we can't know that the hardware path option is being exercised unless we can detect a hardware signature in the analogue output. I assume it's the same for an Audigy? And, when a "hardware path" exists - why ship a "software path" at all?

Hi,
OIpenAL architecture works the following way by default: The application only has direct dependency on the OpenAL router (OpenAL32.dll). The router enumerates the real driver implementations and ranks them according to feature sets etc. (HW implementations have a higher priority). Then the router redirects the application calls either to the default driver or to the one that has been explicitly specified by the application.
Most OpenAL games/software relies on the router to select a default driver and do not specify an explicit driver name to use.
Usually this is why it's problematic to determine what driver is actually used by the application.

But knowing the OpenAL architecture can help making sure that you use only the driver implementation that you want to test/use. That is:
The default OpenAL router (OpenAL32.dll) is actually optional. You can always rename a specific hardware/software driver implementation to OpenAL32.dll and copy it to the application's folder. In this case there is no router to redirect calls and the application calls the exports of the specific driver directly. This way you can make sure that no other alternative driver or software callback is involved.
In practice this means that e.g. if you rename ct_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then only the Audigy/X-fi HW driver is used.
In this case you can also experience that the application can only work with Audigy/X-fi cards. For all other cards you will get an initialization error, no software fallback is available.

The attachment direct_hw_openal.png is no longer available

On the other hand if you rename wrap_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then always the fallback is used even in case of Audigy/X-fi cards.

The attachment fallback_sw_openal.png is no longer available

BTW, the first software fallback driver (wrap_oal.dll) by Creative was part of the OpenAL redistributable (oalinst.exe) since the earliest days of OpenAL. This driver was written by Creative originally for all other cards that do not have direct HW implementations. But of course it can even work with cards that do have HW implementations.

The sens_oal.dll driver is similar to soft_oal.dll driver in the sense that it provides full 3d positional audio and EAX implementation without relying on specific hardware features. It's a software only driver for post X-fi Creative cards.

No dispute on OpenAL mechanics. But, OpenAL does not communicate directly with silicone. And, the ct_oal.dll is what ultimately decides whether a soft/hard DSP is exercised.

You are describing the top part of the diagram and ignoring the bottom part of the same diagram:

Copy code to clipboard

1OpenAL  -  ct_oal.dll  
2                        ├─ hardware DSP path (ha20x2k.sys)
3                        └─ software DSP path (cthda.sys)

Renaming the file doesn't change the pathways:

Copy code to clipboard

1OpenAL  - openal32.dll  
2                         ├─ hardware DSP path (ha20x2k.sys)
3                         └─ software DSP path (cthda.sys)

My understanding is that Creative provided a software path for hardware silicone because they knew NT6 periodically resets states in silicone.

As I said already I have only Audigy and Audigy2 ZS cards. I have found absolutely no evidence for such 2 faced behavior. The only relevant kernel drivers are ctaud2k.sys and ha10kx2k.sys. There is no trace of cthda.sys at all.
And ct_oal.dll always behaves the same way never using software mixing as I have already presented above.

Falcosoft wrote on 2026-01-25, 14:10:

MattRocks wrote on 2026-01-25, 12:52:

No dispute on OpenAL mechanics. But, OpenAL does not communicate directly with silicone. And, the ct_oal.dll is what ultimately […]
Show full quote

Falcosoft wrote on 2026-01-25, 10:55:

Hi, OIpenAL architecture works the following way by default: The application only has direct dependency on the OpenAL router (Op […]
Show full quote

Hi,
OIpenAL architecture works the following way by default: The application only has direct dependency on the OpenAL router (OpenAL32.dll). The router enumerates the real driver implementations and ranks them according to feature sets etc. (HW implementations have a higher priority). Then the router redirects the application calls either to the default driver or to the one that has been explicitly specified by the application.
Most OpenAL games/software relies on the router to select a default driver and do not specify an explicit driver name to use.
Usually this is why it's problematic to determine what driver is actually used by the application.

But knowing the OpenAL architecture can help making sure that you use only the driver implementation that you want to test/use. That is:
The default OpenAL router (OpenAL32.dll) is actually optional. You can always rename a specific hardware/software driver implementation to OpenAL32.dll and copy it to the application's folder. In this case there is no router to redirect calls and the application calls the exports of the specific driver directly. This way you can make sure that no other alternative driver or software callback is involved.
In practice this means that e.g. if you rename ct_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then only the Audigy/X-fi HW driver is used.
In this case you can also experience that the application can only work with Audigy/X-fi cards. For all other cards you will get an initialization error, no software fallback is available.

The attachment direct_hw_openal.png is no longer available

On the other hand if you rename wrap_oal.dll to openal32.dll and you copy this openal32.dll to the application's folder then always the fallback is used even in case of Audigy/X-fi cards.

The attachment fallback_sw_openal.png is no longer available

BTW, the first software fallback driver (wrap_oal.dll) by Creative was part of the OpenAL redistributable (oalinst.exe) since the earliest days of OpenAL. This driver was written by Creative originally for all other cards that do not have direct HW implementations. But of course it can even work with cards that do have HW implementations.

The sens_oal.dll driver is similar to soft_oal.dll driver in the sense that it provides full 3d positional audio and EAX implementation without relying on specific hardware features. It's a software only driver for post X-fi Creative cards.

No dispute on OpenAL mechanics. But, OpenAL does not communicate directly with silicone. And, the ct_oal.dll is what ultimately decides whether a soft/hard DSP is exercised.

You are describing the top part of the diagram and ignoring the bottom part of the same diagram:

Copy code to clipboard

1OpenAL  -  ct_oal.dll  
2                        ├─ hardware DSP path (ha20x2k.sys)
3                        └─ software DSP path (cthda.sys)

Renaming the file doesn't change the pathways:

Copy code to clipboard

1OpenAL  - openal32.dll  
2                         ├─ hardware DSP path (ha20x2k.sys)
3                         └─ software DSP path (cthda.sys)

My understanding is that Creative provided a software path for hardware silicone because they knew NT6 periodically resets states in silicone.

As I said already I have only Audigy and Audigy2 ZS cards. I have found absolutely no evidence for such 2 faced behavior. The only relevant kernel drivers are ctaud2k.sys and ha10kx2k.sys. There is no trace of cthda.sys at all.
And ct_oal.dll always behaves the same way never using software mixing as I have already presented above.

If there is no software path available, then it's proven for Audigy. I was wondering about how to ID and remove software paths to arrive at that state for X-Fi Titanium HD.

Falcosoft wrote on 2026-01-25, 14:10:

As I said already I have only Audigy and Audigy2 ZS cards. I have found absolutely no evidence for such 2 faced behavior. The only relevant kernel drivers are ctaud2k.sys and ha10kx2k.sys. There is no trace of cthda.sys at all.

For reference, there is no cthda.sys on my Win10 system with an X-Fi Titanium Fatal1ty Professional (SB0886) either.

Joseph_Joestar wrote on 2026-01-25, 14:43:

Falcosoft wrote on 2026-01-25, 14:10:

As I said already I have only Audigy and Audigy2 ZS cards. I have found absolutely no evidence for such 2 faced behavior. The only relevant kernel drivers are ctaud2k.sys and ha10kx2k.sys. There is no trace of cthda.sys at all.

For reference, there is no cthda.sys on my Win10 system with an X-Fi Titanium Fatal1ty Professional (SB0886) either.

I am feeling a bit numb right now because the summary of all online complaints about Vista audio collapses to users simply misconfiguring their systems!

If you continue running the NT6 EAX test with hardware mixing, and in the middle of that test you play a Windows audio sound - does the Windows audio simply play on top of the EAX audio as it would on NT5?

The NT6 WASAPI cannot see anything of the OpenAL kernel-stream, so if that test works then NT5 style sound card mixing is fully functional on NT6. Does that rewrite history?