Ending the Windows Audio Quality Debate

[Davide]

Nice.

Sample peak,          RMS
-20.00 dBFS,  -20.00 dBFS - intersample.flac
-13.24 dBFS,  -56.20 dBFS - sox_rate_8x.flac
 -8.02 dBFS,  -43.97 dBFS - sox_rate_b997_8x.flac

View attachment 300065
View attachment 300066

I'm assuming the samples are spaced at 44.1kHz, so the signal is at 22.05kHz, correct?
But in this case, shouldn't the true peak be reduced with the LPF?

 

[MaxwellsEq]

View attachment 300066

I've not sent this before. Obviously a synthetic signal, but fascinating. I wonder what would happen if someone cut this into a piece of normal music.

 

[danadam]

I'm assuming the samples are spaced at 44.1kHz

No need to assume, the file is attached there

so the signal is at 22.05kHz, correct?

Yes, as also shown in the spectrum there.

But in this case, shouldn't the true peak be reduced with the LPF?

Well, it is, but the steeper the filter the less reduction, because most of the energy is near Fs/2. Maybe the spectrum of all three will make it clearer:

 

[bennetng]

No need to assume, the file is attached there


Yes, as also shown in the spectrum there.


Well, it is, but the steeper the filter the less reduction, because most of the energy is near Fs/2. Maybe the spectrum of all three will make it clearer:
View attachment 300264

Using SoX's rate without additional switches would be too optimistic when compared to typical DAC on-chip filters. Try something like this:

Digital filter "game"

Some of you probably have seen a lot of filter plots like these on DAC datasheets: How about making these things without using specialized software like Matlab, Octave and such? They are not particularly easy to use. So many people just "see" them rather than try to figure out the meaning...

www.audiosciencereview.com

No, I am not saying the intersample over caused by this test signal can make someone's hi-fi system explode, cause smoke to amp etc. If anything, the high frequency content excluding the click in the middle are already harmful enough if the test file is generated at 0dBFS instead of -20dBFS.

I attached an actual recording from a Realtek's analog output using exclusive mode then recorded by my Creative soundcard's ADC input using 96kHz, which is the highest supported recording rate of the Creative card. I made a few modifications to the test file as the Realtek runs natively at 48kHz, so I adjusted the sample rate of the file (not resample) to 48kHz, also I increased the level of the file to 0dBFS so that I can observe the clipping behaviour caused by the Realtek.

96kHz recording rate is not very high, to make things clearer I also included a full scale sweep from 18kHz to 23.999kHz using the exact same cofiguration so that the transition curve of the Realtek can be identified much easier. Also some idle noise are included for reference. The PC has a GPU card insatalled, so it is not very clean, but these things are irrelevant to intersample over.

If you are interested about the performace of the Realtek and the Creative soundcard, here are some measurements:

Can't get Asus Xonar SE detected on new hardware (e.g. Z590 / other Intel 5xx)? Try this.

My shiny new Asus TUF Gaming Z590-Plus WIFI (now that's a mouthful) mamaboard would not detect a Xonar SE soundcard by the very same manufacturer (oops). On top of that, the Intel I225-V onboard LAN would disappear when the card was inserted. :facepalm: At the same time, the card was proven to...

www.audiosciencereview.com

Can't get Asus Xonar SE detected on new hardware (e.g. Z590 / other Intel 5xx)? Try this.

My shiny new Asus TUF Gaming Z590-Plus WIFI (now that's a mouthful) mamaboard would not detect a Xonar SE soundcard by the very same manufacturer (oops). On top of that, the Intel I225-V onboard LAN would disappear when the card was inserted. :facepalm: At the same time, the card was proven to...

www.audiosciencereview.com

Also, while it is just mentioned a few pages before, others can try my test signal as well, which is pretty much immune to filter steepness because the signal does not contain anything very close to Nyquist.

Invitation: Audible intersample clipping test

The test signal is attached at the end of this post: https://forum.cockos.com/showthread.php?t=201868 Basically I don't like the idea of blaming those who make music or DACs for intersample clipping since there is no absolute clipping point. My test signal is a bit more sophisticated than the...

www.audiosciencereview.com

 

[Davide]

I followed your instructions carefully, but I can only detect events with Foobar in WASAPI Shared.
If I use Exclusive nothing appears.
Also, with Amazon Music (default and exclusive) and VLC nothing appears.
Could this be the fault of my lightened version of Windows with NTLite?

Maybe I figured out where the catch is.
Some applications use portaudio to access WASAPI, and thus monitoring their process is not sufficient to intercept that driver engagement information.
I became aware of this while monitoring Audacity and VLC, where at some point an entry appeared in API Monitor, related to portaudio_x64.dll, and no other information about WASAPI, despite being set as an output driver.
In fact these two applications appear to use portaudio from the related site.
Is there some way to monitor what happens inside portaudio then?
@edechamps Could you kindly give me feedback?

 

[edechamps]

Some applications use portaudio to access WASAPI, and thus monitoring their process is not sufficient to intercept that driver engagement information.
I became aware of this while monitoring Audacity and VLC, where at some point an entry appeared in API Monitor, related to portaudio_x64.dll, and no other information about WASAPI, despite being set as an output driver.
In fact these two applications appear to use portaudio from the related site.
Is there some way to monitor what happens inside portaudio then?
@edechamps Could you kindly give me feedback?

Yeah, I've noticed that as well when trying to use API Monitor on FlexASIO (which uses PortAudio). I have no idea why it doesn't work on PortAudio. I can't think of any reason why it wouldn't. I'll see if I can investigate that when I have some time.

 

[edechamps]

@Davide I figured it out. The problem is that PortAudio calls IMMDevice::Activate() passing the IID not for IAudioClient, but for IAudioClient3. Problem is, API Monitor is a fairly old piece of software (2013) - it doesn't know about IAudioClient3 which first appeared in Windows 10 (i.e. in 2015). This means API Monitor doesn't understand the interface of the COM object being returned from IMMDevice::Activate() and is therefore unable to trace any of the follow on WASAPI calls that are being made on that object.

Thankfully, it is possible to tell API Monitor about API definitions it doesn't know about. I created an API definition file by hand for IAudioClient3 - please find attached. Unpack the zipfile in C:\Program Files\rohitab.com\API Monitor\API\Interfaces\CoreAudio (alongside IAudioClient.xml and IAudioClient2.xml), check "Disable caching" in the API Monitor General Options to force it to reload its API definitions, restart API Monitor then make sure IAudioClient3 is checked under "Audio and Video" > "Core Audio" > "Windows Audio Session". From that point on it should be able to trace PortAudio WASAPI calls and you should see calls to IAudioClient3::Initialize(). Enjoy!

 

[Davide]

@Davide I figured it out. The problem is that PortAudio calls IMMDevice::Activate() passing the IID not for IAudioClient, but for IAudioClient3. Problem is, API Monitor is a fairly old piece of software (2013) - it doesn't know about IAudioClient3 which first appeared in Windows 10 (i.e. in 2015). This means API Monitor doesn't understand the interface of the COM object being returned from IMMDevice::Activate() and is therefore unable to trace any of the follow on WASAPI calls that are being made on that object.

Thankfully, it is possible to tell API Monitor about API definitions it doesn't know about. I created an API definition file by hand for IAudioClient3 - please find attached. Unpack the zipfile in C:\Program Files\rohitab.com\API Monitor\API\Interfaces\CoreAudio (alongside IAudioClient.xml and IAudioClient2.xml), check "Disable caching" in the API Monitor General Options to force it to reload its API definitions, restart API Monitor then make sure IAudioClient3 is checked under "Audio and Video" > "Core Audio" > "Windows Audio Session". From that point on it should be able to trace PortAudio WASAPI calls and you should see calls to IAudioClient3::Initialize(). Enjoy!

Thank you!
You are really super competent!
I'll do some tests as soon as possible.

 

[howard416]

"Use original APO" is greyed out for me. Is it because the drivers for my Ultralite mk5 have removed all the Windows garbage, or is there some other reason and I should do whatever I can to turn that "on"?

 

[dasdoing]

"Use original APO" is greyed out for me. Is it because the drivers for my Ultralite mk5 have removed all the Windows garbage, or is there some other reason and I should do whatever I can to turn that "on"?

afaiui the "garbage" would be in the driver and the Motu driver just doesn't have an apo. Motu processing is in the hardware itself

 

[howard416]

afaiui the "garbage" would be in the driver and the Motu driver just doesn't have an apo. Motu processing is in the hardware itself

So, I am OK without that option, then?

 

[dasdoing]

So, I am OK without that option, then?

sure

 

[Zardozz]

Sorry for jumping in 2 years after reading only the OP's first post. Looking forward to reading more of this thread later, so posting here will help me find it!

All I can say is WOW, WOW, WOW. It's like a Schiit Decrapifier for Windows, all puns intended!

I followed the advice (with a few changes I'll tell below), and I swear my audio quality took a big jump. No I can't do AB testing so easily because it takes a long time to go back and forth, with rebooting even required. But if this is just a placebo effect then smoke 'em if you got 'em because it sure sounds better to me!

DDF deserves a nobel prize in SQ.

OK here's what I did a little differently:
1. Instead of doing -0.2dB preamp to "avoid CAudioLimiter", I just hated the idea of trusting that thing at all. Who knows what else it's doing? Also I don't like the idea of being forced to use EQ in order to avoid DSP. And ya know, volume adjustment of bits in a downward right-shift motion is theoretically safe but it's still not bitperfect. What if I could just do a clean passthrough by ripping out CAudioLimiter totally? Yeah, that's what I did. What if I was a clean pass through? So I just removed it totally from the DSP signal path. Removed the Windows nanny APO.

2. For the same reason, I don't want to do -4dB to avoid oversampling making unwanted summing over 0dB. So I just use exclusive mode to play music, no problem there.

3. I did do the "troubleshoot mode" to remove the original APO that apparently gets forced onto my DAC, as DDF explained.

Anyway, I'm really happy and kudos to everyone that made this info possible.

 

[edechamps]

Removed the Windows nanny APO.
I just use exclusive mode to play music
I did do the "troubleshoot mode" to remove the original APO

There is no need to go through all this trouble: exclusive mode bypasses all APOs, so if you use exclusive mode it doesn't matter which APOs are installed.

 

[Zardozz]

There is no need to go through all this trouble: exclusive mode bypasses all APOs, so if you use exclusive mode it doesn't matter which APOs are installed.

Yes you're right, and exclusive mode is absolutely great when I want clean passthrough with no DSP or Equalizer APO. Even so, I'm not sure that CAudioLimiter is ever disabled. Maybe someone else knows.

On the other hand, if I'm listening to old recordings where they do stuff like bass in one ear only and guitar in the other ear only, that Jan Meier crossfeed in Equalizer APO makes the music just so much better.

 

[edechamps]

Yes you're right, and exclusive mode is absolutely great when I want clean passthrough with no DSP or Equalizer APO. Even so, I'm not sure that CAudioLimiter is ever disabled.

CAudioLimiter is bypassed in exclusive mode, just like all other APOs and the rest of the Windows Audio Graph (mixing, resampling, etc.). WASAPI Exclusive mode is guaranteed to be bit-perfect as it gives the application direct access to the DAC's hardware buffers.

 

[Mulder]

CAudioLimiter is bypassed in exclusive mode, just like all other APOs and the rest of the Windows Audio Graph (mixing, resampling, etc.). WASAPI Exclusive mode is guaranteed to be bit-perfect as it gives the application direct access to the DAC's hardware buffers.

Problem here is that not all software are able to use WASAPI. My Spotify client for example.

 

[dasdoing]

the new mixer in W11 is disapointing. I thought I would be able to direct output on a software to device basis there like you can do in "settings". It added basically nothing at all

 

[192kbps]

WinSoftVol: force Windows software volume control

GitHub - dechamps/WinSoftVol: A Windows filter driver that disables hardware volume control on audio devices.

A Windows filter driver that disables hardware volume control on audio devices. - dechamps/WinSoftVol

github.com

 

[anphex]

It's insane. I just did the trick with uninstalling the original APOs and the difference was one of the biggest I ever head. This probably was the final barrier to maximum audible transparency. Now even in complex and/or loud parts I usually found annoying everything is just ... sorted out and transparent. It actually makes my shake head how easy it was this whole time and how much of in impact it has. This is impact is far beyond all those tiny annoyances I might have with DAC roll off filters and the like. This should be a mayor PSA sticky for all Windows users.

Makes me think if I could have shortened my audio equipment voyage just by applying this trick beforehand. Then again, this thread only exists for two years.