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

I am feeling a bit numb right now because the summary of all online complaints about Vista audio collapses to users simply misco […]
Show full quote

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?

Yes, of course. Other audio/Windows sounds play on top of the OpenAL EAX audio. Test video:
https://youtu.be/SwoiDzsF27M

I have only expletives left. For decades I (and most commentary) believed NT5 audio pathways were dead on NT6.

And for a bigger sting,

"My last ALchemy release (1.00.08) was complately unlocked and could be used with any sound device from any vendor." - Daniel K
https://community.pcgamingwiki.com/files/file … hemy-universal/

I am thinking about something not directly related to EAX so feel free to tell me if i'm off topic but i've had the X-Fi Titanium installed for a few months in my overpowered XP/7 build and only tried it under XP yesterday. I notice a lot of stuttering in Far Cry and Crysis. I'm not sure if maybe i didn't notice it before and these games just run smoother under Win7 or switching from the Audigy RX to the X-Fi caused this.

OM606 wrote on 2026-01-26, 18:30:

I am thinking about something not directly related to EAX so feel free to tell me if i'm off topic but i've had the X-Fi Titanium installed for a few months in my overpowered XP/7 build and only tried it under XP yesterday. I notice a lot of stuttering in Far Cry and Crysis. I'm not sure if maybe i didn't notice it before and these games just run smoother under Win7 or switching from the Audigy RX to the X-Fi caused this.

Which driver version are you using? I've seen some reports of this happening with both the latest official drivers from Creative, and with DanielK's last X-Fi pack under WinXP.

When using an X-Fi Titanium on WinXP, you generally want to use older drivers. Check my guide if you haven't already.

I've been using 2.17.0008 and 2.17.0009. i'm also having issues with occasional BSOD in some OpenAL games under 7 x64 since installing the X-Fi.

OM606 wrote on 2026-01-26, 18:42:

I've been using 2.17.0008 and 2.17.0009. i'm also having issues with occasional BSOD in some OpenAL games under 7 x64 since installing the X-Fi.

Might be related to having the Audigy in the system beforehand.

Creative's drivers don't uninstall completely from the Control Panel, and there are always some leftover files hanging around, which could potentially cause conflicts. A clean OS install might help, if that's indeed the cause of your issues. But it could also be something else entirely.

This is after a clean install of both OS. Yeah it could possibly be something different or me getting used to no stutter under Win7 and noticing it under XP. It seems that Audigy cards might be a slightly more trouble free if we take into consideration problems like the OpenAL BSOD issue under Vista+. I've heard that 2.17.0008c drom 2011 fixes this issue but i'm not sure.

OM606 wrote on 2026-01-26, 19:31:

It seems that Audigy cards might be a slightly more trouble free if we take into consideration problems like the OpenAL BSOD issue under Vista+.

For what it's worth, I've never encountered one of those on my X-Fi Titanium under Win7 or Win10.

OM606 wrote on 2026-01-26, 19:31:

This is after a clean install of both OS. Yeah it could possibly be something different or me getting used to no stutter under Win7 and noticing it under XP. It seems that Audigy cards might be a slightly more trouble free if we take into consideration problems like the OpenAL BSOD issue under Vista+. I've heard that 2.17.0008c drom 2011 fixes this issue but i'm not sure.

This is exactly the widely reported behaviour that led me to argue that for THD there are two mixing paths - one that is smooth, and one that stutters. And, the user isn’t choosing a path.

The demo shows windows mixer didn’t interfere with Audigy hardware mixing , and that completely stunned me.

Maybe this “research” needs to be done without Audigy cards because maybe there are architectural and strategic differences and what fixes one might not fix the other?

MattRocks wrote on 2026-01-27, 06:59:

Maybe this “research” needs to be done without Audigy cards because maybe there are architectural and strategic differences and what fixes one might not fix the other?

I was able to reproduce Falcosoft's findings on my X-Fi Titanium under Win10 without any issues.

That said, X-Fi cards are now almost 20 years old, so it's possible that some of their capacitors have dried out, which could result in seemingly random BSODs. While brand new Audigy RX cards (which are still being sold) wouldn't suffer from that.

Joseph_Joestar wrote on 2026-01-27, 08:03:

MattRocks wrote on 2026-01-27, 06:59:

Maybe this “research” needs to be done without Audigy cards because maybe there are architectural and strategic differences and what fixes one might not fix the other?

I was able to reproduce Falcosoft's findings on my X-Fi Titanium under Win10 without any issues.

That said, X-Fi cards are now almost 20 years old, so it's possible that some of their capacitors have dried out, which could result in seemingly random BSODs. While brand new Audigy RX cards (which are still being sold) wouldn't suffer from that.

Here's a discussion from 2010 before the caps could have dried:
https://hardwarecanucks.com/forum/threads/cre … uttering.31544/

In that particular case the user reinstalled Windows and didn't report back, so we can assume the audio worked better when the Windows installer found the X-Fi during its initial setup. Lots of different variables to try: AC'97 enabled/disabled, supported formats, power/sleep settings, Widows audio effects, etc. In decades of confused debates nobody has populated a comprehensive truth table, probably because most users don't actually want to diagnose the root cause - they just want their audio fixed.

If smooth consistent hardware mixing works for one person (e.g. yourself) then it can work for anyone if they have the same configuration.

MattRocks wrote on 2026-01-27, 10:47:

Here's a discussion from 2010 before the caps could have dried:
https://hardwarecanucks.com/forum/threads/cre … uttering.31544/

My response was to the issue that OM606 experienced, since he said that he had an Audigy RX in the system before. I never said that it was the root cause for all the problems that people had with these cards.

All I can say is, my own X-Fi Titanium works fine under both WinXP and Win10. And I can reproduce all of Falcosoft's tests perfectly under Win10, including the windows mixer not affecting OpenAL output.

Joseph_Joestar wrote on 2026-01-27, 10:56:

MattRocks wrote on 2026-01-27, 10:47:

Here's a discussion from 2010 before the caps could have dried:
https://hardwarecanucks.com/forum/threads/cre … uttering.31544/

My response was to the issue that OM606 experienced, since he said that he had an Audigy RX in the system before. I never said that it was the root cause for all the problems that people had with these cards.

All I can say is, my own X-Fi Titanium works fine under both WinXP and Win10. And I can reproduce all of Falcosoft's tests perfectly under Win10, including the windows mixer not affecting OpenAL output.

Working hypothesis: If we have only one X-Fi card throughout the Windows lifespan, that X-Fi is stable. And, if we swap cards, we create a history of automatically changed software settings some of which may cause X-Fi instability. Don't know, but that seems to fit the curve 😉

Joseph_Joestar wrote on 2026-01-15, 11:55:

...

For a proper test, we would need something akin to MSI Afterburner which can display an in-game overlay. But instead of showing FPS, it would display free/used hardware buffers and X-RAM in real time.

I have added real time 'used buffers'monitoring to my OpenAL test program.
I could not find direct function calls that could give back this info so I had to make a rather obscure implementation. At every cycle the program opens a new context and tries to create as many buffers as possible without errors. When an error occurs it finishes the buffers creation process and registers the number of the successfully created buffers. This process can interfere with games so it should be used only for 'used buffers' testing.

Here is a test video about Quake4.
Notice that while the Audigy has 63 free buffers by default the recording through the 'What You Hear' device occupies 6 buffers so only 57 is available at the start of the video:
https://youtu.be/N7PgB5-dRPc

Here is the program itself (updated to version 1.2!):

Falcosoft wrote on 2026-01-27, 17:34:

I have added real time 'used buffers'monitoring to my OpenAL test program.

Wow, nice work! I'll definitively give this a try.

Falcosoft wrote on 2026-01-27, 17:34:

This process can interfere with games so it should be used only for 'used buffers' testing.

This does concern me a bit. What would happen if a game tries to use more buffers? Would the test program interfere with that?

Falcosoft wrote on 2026-01-27, 17:34:

Here is a test video about Quake4.
Notice that while the Audigy has 63 free buffers by default the recording through the 'What You Hear' device occupies 6 buffers so only 57 is available at the start of the video:
https://youtu.be/N7PgB5-dRPc

Just to confirm if I understand this correctly. In your video, there were 23 buffers available out of 57 in the minimum field. Does that mean that during your particular test, Quake 4 used 34 buffers as a peak value?

I also noticed how the number of used buffers increased when you were firing your weapon, which leads me to believe that in a proper firefight between multiple people, this number would likely go up even further.

Joseph_Joestar wrote on 2026-01-27, 17:51:

Wow, nice work! I'll definitively give this a try. […]
Show full quote

Falcosoft wrote on 2026-01-27, 17:34:

I have added real time 'used buffers'monitoring to my OpenAL test program.

Wow, nice work! I'll definitively give this a try.

Falcosoft wrote on 2026-01-27, 17:34:

This process can interfere with games so it should be used only for 'used buffers' testing.

This does concern me a bit. What would happen if a game tries to use more buffers? Would the test program interfere with that?

Falcosoft wrote on 2026-01-27, 17:34:

Here is a test video about Quake4.
Notice that while the Audigy has 63 free buffers by default the recording through the 'What You Hear' device occupies 6 buffers so only 57 is available at the start of the video:
https://youtu.be/N7PgB5-dRPc

Just to confirm if I understand this correctly. In your video, there were 23 buffers available out of 57 in the minimum field. Does that mean that during your particular test, Quake 4 used 34 buffers as a peak value?

I also noticed how the number of used buffers increased when you were firing your weapon, which leads me to believe that in a proper firefight between multiple people, this number would likely go up even further.

1. Yes, it's possible. But there is no other way to get more accurate results. The OpenAL API has no functions to query free/used HW buffers directly.
On my I7-4770 system one 'get buffers/free buffers' cycle is about ~10 ms. The process repeats at 200 ms intervals. So there is roughly 1/20 chance that the game and the monitoring program overlap.
It depends on the game what it does in this case. If it tries again then the next attempt most likely will be successful.

2. Yes, your interpretation is correct. This works the same way as in case of AIDA64.

3. Yes, it's very likely. But I'm not a multiplayer guy so you have to test this hypothesis.

@Edit:
I realized why 'What You Hear' recording reserved 6 buffers. It's because my Audigy is set to 5.1 output. If I change the Windows setting to 2 channel/stereo then only 2 buffers are reserved in case of recording (so 61 is available).

Falcosoft wrote on 2026-01-27, 18:30:

3. Yes, it's very likely. But I'm not a multiplayer guy so you have to test this hypothesis.

Well, I can't do multiplayer these days either (except with bots). But here's my quick test of Prey single player with a 2-3 enemies on screen:

If I'm reading this correctly, Prey is using 127-57=70 hardware voices at this time? That already exceeds what Audigy cards are capable of, and it's not even a particularly busy scene. When I have more time, I'll try to do some more thorough testing.

Joseph_Joestar wrote on 2026-01-27, 18:55:

Well, I can't do multiplayer these days either (except with bots). But here's my quick test of Prey single player with a 2-3 ene […]
Show full quote

Falcosoft wrote on 2026-01-27, 18:30:

3. Yes, it's very likely. But I'm not a multiplayer guy so you have to test this hypothesis.

Well, I can't do multiplayer these days either (except with bots). But here's my quick test of Prey single player with a 2-3 enemies on screen:

The attachment Prey_OpenAL_Test01.jpg is no longer available

If I'm reading this correctly, Prey is using 127-57=70 hardware voices at this time? That already exceeds what Audigy cards are capable of, and it's not even a particularly busy scene. When I have more time, I'll try to do some more thorough testing.

If you get 127 for actual/minimum values when nothing is running and you start monitoring then your calculation is correct.

Falcosoft wrote on 2026-01-27, 19:02:

If you get 127 for actual/minimum values when nothing is running and you start monitoring then your calculation is correct.

Yep, I get 127 when I first start up your OpenAL Test utility and click the "Start Monitoring" button, with nothing else running in the background. So I guess this proves that Prey can use at least 70 hardware voices simultaneously. Possibly more during busier scenes with more enemies on screen.

If someone else wants to test this, I'm attaching the relevant savegame. Just walk through the corridor, use the handprint terminal to open the door, and start shooting at the enemies there.

I have updated my OpenALTest program to version 1.2. The post of the original download is modified.
The results should be the same. The only thing that is fixed is a huge memory leak. Version 1.1 ate memory as if there was no tomorrow 😀
Download:
download/file.php?id=235269