Ending the Windows Audio Quality Debate

[Aerith Gainsborough]

Interesting… just to make sure: double check that REW is actually recording, not just playing, at 0 dBFS. I.e. at the top right of the REW RTA it should say 0 dBFS (or ~-0.13 dBFS if CAudioLimiter is active, like in my last screenshot).

REW: 0dBFS, RME: -0.1dBFS on it's display.
Looks like REW gets the signal before it hits the limiter.

And yes: the RME bit perfect testfile does reach 0dBFS, hence no cake in WASABI shared mode.

 

[edechamps]

Looks like REW gets the signal before it hits the limiter.

Strange. Another thing to check is to make sure that the shared mode sample rate configured in the Windows settings for your audio device matches the one you're using in REW (48 kHz). If it's not, sample rate conversion will occur in both directions during the measurement which might invalidate the results. Seems like a long shot though.

Other than that, I'm out of ideas. I don't know why WASAPI loopback shows the effect of the limiter on my system but not yours. Another long shot is that it might be down to Windows version differences (I'm using Windows 11 21H2 22000.652).

 

[Aerith Gainsborough]

Everything is set to 48/24 on playback and recording side.

Other than that, I'm out of ideas. I don't know why WASAPI loopback shows the effect of the limiter on my system but not yours. Another long shot is that it might be down to Windows version differences (I'm using Windows 11 21H2 22000.652).

I'm on Windows 10 21H2 Build 19044.1645. REW version 5.20.7

The only way I can see any limiter action is when I use Java and do a voicemeeter potato loopback. As soon as I set REW to ASIO, the windows stack seems to get bypassed, no matter whether I use RME, HDMI or voicemeeter.

So the limiter is definitely there and doing it's job.

 

[BeerBear]

I made a test of Windows' SRC performance, download here: https://ufile.io/qnotd4kp
Inside are two audio files: the original music clip and the two-times-resampled copy.

The original file (48kHz) was played in MPC-HC (shared mode, non-exclusive), while Windows was set to 44.1kHz and recorded with an internal loopback.
That recording (44.1kHz) was then played with Windows audio set to 48kHz and recorded the same way again. Then it was time aligned with the original to make it easier to compare.

Let me know if you can hear the difference between the two files in a blind test.

For the sake of completeness, here's a test which includes triggering the Windows limiter (both with and without 2x resampling).
So I decided to use a loud track which hits 0dB FS many times. Such loud/clipping releases are unfortunately not rare...
Download here: https://ufile.io/ty0pca74 (All these audio files are copyright-free, BTW.)

Objectively, the differences are much bigger than with only SRC, so I wouldn't be surprised if someone can ABX them this time.

 

[Grooved]

Alright then. I just performed the loopback test with VAC. I played a 24bit file in foobar and recorded it in Reaper, using WASAPI shared mode and the VAC line input. The recording, once time aligned, is identical to the source file (100%, down to the last bit).
I guess I can then confirm that WASAPI shared is bit-perfect even through hardware (with the caveats already mentioned in my last post).


If the volume is at max, but the signal doesn't reach -0.14dB (or whatever is the exact value), the limiter won't be triggered.
Granted, a lot of music goes over that level... And I assume whatever RME is using for testing bit-perfect playback goes over that too.

NOTE: Not checked recently but I tested both VB-Audio Cable and VB HiFi Cable some months ago (and Voicemeeter I think) , and I believe that only HiFi Cable had good result up to 192kHz

 

[BeerBear]

It's possible, yes, I don't know much about VB-Audio Cable. What I used was Virtual Audio Cable (VAC), and I confirm that it produces a bit-perfect recording even at 192kHz.
I believe @edechamps when he says that VAC simulates an audio driver properly, so that we can inspect what happens in Windows without using hardware.
But since you have digital i/o you can also do this test with an actual cable, by recording the output of a media player (in shared mode). Audacity works just fine for this. Just make sure, if you're playing at max volume, that the file you're using peaks at below -0.14dB. (The files I uploaded here peak at -6dB, for instance.)
Then the recording can be compared to the original. You can verify they're identical in various ways, also with DeltaWave, which you already know.

 

[Grooved]

It's possible, yes, I don't know much about VB-Audio Cable. What I used was Virtual Audio Cable (VAC), and I confirm that it produces a bit-perfect recording even at 192kHz.
I believe @edechamps when he says that VAC simulates an audio driver properly, so that we can inspect what happens in Windows without using hardware.
But since you have digital i/o you can also do this test with an actual cable, by recording the output of a media player (in shared mode). Audacity works just fine for this. Just make sure, if you're playing at max volume, that the file you're using peaks at below -0.14dB. (The files I uploaded here peak at -6dB, for instance.)
Then the recording can be compared to the original. You can verify they're identical in various ways, also with DeltaWave, which you already know.

OK, I misread it and thought it was VB-Audio Cable.
I will try with it too, and with internal SPDIF and SPDIF on some audio interfaces to see if going via USB or Firewire can change something for the ones with a WDM driver

 

[square.]

The -4dB is not necessary if you are not using filters. -0.2dB should be sufficient. Too much lowering unnecessarily will have implications downstream on gain matching.

If I am using a -4db low shelf filter for the highs on my speakers on my RME ADI 2 FS equalizer will I also need to do -4dB on eAPO or will RME do this automatically for me?

I do use -0.2dB to avoid the distortion issues but I am unclear on wether the extra -4db on eAPO is needed or not due to the fact RME uses their own drivers for windows pc's.

Anyone have any thoughts on this?

 

[Aerith Gainsborough]

If I am using a -4db low shelf filter for the highs on my speakers on my RME ADI 2 FS equalizer will I also need to do -4dB on eAPO or will RME do this automatically for me?

I do use -0.2dB to avoid the distortion issues but I am unclear on wether the extra -4db on eAPO is needed or not due to the fact RME uses their own drivers for windows pc's.

Anyone have any thoughts on this?

If you address the device via the Madiface ASIO driver, you do not need either, the -0.2dB or the -4dB because you already bypass the windows audio stack.

Also, if you do not use any eAPO filters, there is no need to create any headroom software side, which is the point of the -4dB preamp setting.
The RME has internal headroom when you use it's own EQ.

Personally, I would not bother with eAPO at all unless you need more than the 7 bands that the RME can provide.

 

[HammerSandwich]

if you do not use any eAPO filters, there is no need to create any headroom software side, which is the point of the -4dB preamp setting.

You'll avoid inter-sample overs, but CALimiter would remain an issue, yes? IOW, leave 1dB headroom, not 4.

 

[Aerith Gainsborough]

You'll avoid inter-sample overs, but CALimiter would remain an issue, yes? IOW, leave 1dB headroom, not 4.

None of that is relevant when he uses ASIO. The device Operating system does not need to resample because the RME switches sample rate according to track.

 

[edechamps]

FYI, I took the liberty of writing a notes doc about the technical details of how APOs work and how to manipulate their configuration. Hopefully someone will find it useful.

 

[Aerith Gainsborough]

All properties are optional. If no properties are present, or if the FxProperties key is absent entirely, then no system effect APOs are used.

Interesting read, thanks.
No FxProperties installed for Dirac Live standalone but quite a few for the RME ADI-2 DAC. Since I'm sure the RME DEVs had good reason for including the APO's I'll leave them be.

A word of caution to unsuspecting readers, thinking they can "improve" audio quality with a quick fix:
It is ill-advised to randomly delete or change registry keys unless you know exactly what you are doing.
Unexpected / unwanted behavior of the system can be the consequence.

 

[edechamps]

No FxProperties installed for Dirac Live standalone but quite a few for the RME ADI-2 DAC. Since I'm sure the RME DEVs had good reason for including the APO's I'll leave them be.

RME devs might not have anything to do with it. If they are using the standard Microsoft USB Audio driver then that might be where the sAPO configuration is coming from. (The Microsoft USB Audio driver typically configures a standard suite of Microsoft sAPOs.)

You can confirm this by locating the sAPOs and determining if the sAPOs CLSIDs are pointing to a Microsoft DLL or an RME one.

 

[Aerith Gainsborough]

Good point.

The first 2 CLSIDs point to WMALFXGFXDSP.dll (WM LFX APO & WM GFX APO) and the 3rd one to SysFxUI.dll (CplPage Class).
Both sitting in C:\Windows\system32.

So they are probably from the standard USB driver.

 

[edechamps]

So here's something I'm sure people in this thread would find interesting: I found a way to completely remove CAudioLimiter from the audio path!

What I realized is that CAudioLimiter is an APO like any other, and like all APOs, it has its own registered COM class with its own CLSID. This blog post has the CLSID - it's {D69E0717-DD4B-4B25-997A-DA813833B8AC}. We can deliberately mess up that class registration so that the Windows audio engine cannot find it anymore. Luckily, if the Windows audio engine can't load that APO, then audio still works - it just bypasses the missing APO!

Here's the procedure:

1. In the Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{D69E0717-DD4B-4B25-997A-DA813833B8AC}.
2. You're gonna have to mess with the permissions to be able to make the required changes. Change the owner of the InProcServer32 subkey to Administrators, then give Administrators Full control.
3. Make any change that would prevent the class from being loaded. For example, change the (default) value to add a "DISABLED" prefix so that the path to audioeng.dll is broken.
4. Restart the Windows Audio service (audiosrv).

After I did this, audio still worked fine but I was unable to trigger the limiter - the audio pipeline goes all the way up to 0.00 dBFS without any additional distortion. I think it should be truly bit-perfect now (in 24-bit at least - in 16-bit there is still dithering), but I haven't confirmed it.

 

[Aerith Gainsborough]

I think it should be truly bit-perfect now (in 24-bit at least - in 16-bit there is still dithering), but I haven't confirmed it.

RME test file confirms it (tested 44.1 and 96 @ 24bit). At 100% volume setting, the bit perfect test has been passed.

There is a downside to this though: pretty nasty distortion if you happen to mix two audio streams that go to 0dB FS. Tested that by playing back two audio files that both have strong basslines.

So yes: the Limiter may not give lovable SINAD numbers but it is there for a good reason.
I'd leave it alone for general use and stick to ASIO / WASABI Exclusive for critical music listening.

 

[Davide]

in 24-bit at least - in 16-bit there is still dithering

What exactly does this mean? Do you mean the audio stream or output device setting?

 

[edechamps]

@Dlomb11 I mean the shared mode format in the Windows audio device settings. Though keep in mind the Windows audio engine automatically converts all shared mode streams to this format - if you want bit-perfect operation, the stream from the application has to match this format as well.

 

[Davide]

@Dlomb11 I mean the shared mode format in the Windows audio device settings. Though keep in mind the Windows audio engine automatically converts all shared mode streams to this format - if you want bit-perfect operation, the stream from the application has to match this format as well.

View attachment 216031

Ok, thanks.
Another question. Is the limiter also bypassed on the input channels in this way?