Ending the Windows Audio Quality Debate

[Aerith Gainsborough]

Nope, not in these three tests.

You went from 0dBFS to almost -8dBFS in your foobar measurements. There was definitely some heavy attenuation going on in your chain somewhere.

I see no such change when I try this with the RME. There is attenuation, caused by the Windows limiter but not to this degree, Foobar certainly does not seem to do things. Testfile: 0dBFS 1KHz sine 96/24.

Default WASABI shared mode (.... good Wasabi should always be shared!)

ASIO (Madiface driver)

 

[Offler]

You went from 0dBFS to almost -8dBFS in your foobar measurements. There was definitely some heavy attenuation going on in your chain somewhere.

I see no such change when I try this with the RME. There is attenuation, caused by the Windows limiter but not to this degree, Foobar certainly does not seem to do things. Testfile: 0dBFS 1KHz sine 96/24.

Default WASABI shared mode (.... good Wasabi should always be shared!)

Foobar2000 1.6.5 Default: Primary Sound Driver

Foobar with WASAPI - isnt indicated on sound panel at all, because whole Windows stack is bypassed. Its audibly louder, i dont need to measure it.

MPC-HC, System default. Again audibly louder and properly indicated at full loudness on Sound panel.

I ran through the settings of Foobar, there isnt any DSP, no replay gain, no metadata... . Also I played the file on other media players and all of them indicate 100%. Except foobar.

Testfile 0dbFS 1KHz sine 192KHz 24bit.

Its improbable that the driver is the cause I will try reinstall Foobar. But i definitely considered this to be a feature.

 

[Grooved]

foobar2000 in the default shared mode was definitely triggering the limiter last time I checked.

I checked it some months ago by playing a MQA file in Foobar, using ASIO or WASAPI driver, the DAC sees the stream as MQA at 100% full volume, but any small change in volume or DSP make it a non-MQA stream.
Not the perfect test but enough to think it send stream at exact level of the file when selecting a WASAPI or ASIO driver, but maybe not with default output

 

[Aerith Gainsborough]

Not the perfect test but enough to think it send stream at exact level of the file.

Foobar is bit perfect in ASIO mode at 0dB volume.
RME provides test files for that and the DAC indicates whether they are received bit perfect or not.

Another hint is: windows volume control does not work at all.

If you mix two sounds while foobar is playing in ASIO mode, you can control the other sound's volume via windows but not foobar's. Whacky. :'D

Its improbable that the driver is the cause I will try reinstall Foobar. But i definitely considered this to be a feature.

Maybe they have since removed the feature, as I am using 1.6.10.

 

[BeerBear]

Not the perfect test but enough to think it send stream at exact level of the file when selecting a WASAPI or ASIO driver, but maybe not with default output

I just checked now, recording the max volume out from foobar with the internal loopback, using WASAPI shared mode at the source file sample rate.
After time alignment, the recording was 100% bit exact, identical to the original 24bit file. And I believe that's how it gets sent to hardware (but I'd need digital I/O to confirm that). I see no reason why Windows would mess with the signal even in shared mode, unless it's hitting the limiter or needs to be resampled.

So I don't know what's happening in Offler's case... Maybe some config issue or bug or version changes in foobar (I'm also using 1.6.10).

 

[Grooved]

Foobar2000 1.6.5 Default: Primary Sound Driver
View attachment 204651

Foobar with WASAPI - isnt indicated on sound panel at all, because whole Windows stack is bypassed. Its audibly louder, i dont need to measure it.
View attachment 204652

MPC-HC, System default. Again audibly louder and properly indicated at full loudness on Sound panel.
View attachment 204653

I ran through the settings of Foobar, there isnt any DSP, no replay gain, no metadata... . Also I played the file on other media players and all of them indicate 100%. Except foobar.

Testfile 0dbFS 1KHz sine 192KHz 24bit.

Its improbable that the driver is the cause I will try reinstall Foobar. But i definitely considered this to be a feature.

I just tested and if using "Default" in Foobar and one Realtek SPDIF output as default for Windows, I don't get the maximum level in the I/O window (green) but it's just one bar less than full, not half of it like on your capture.

Strange. Did you try after uninstalling the Realtek driver? maybe it changes something, as the default Microsoft driver often allows to use the SPDIF output at 88.2kHz for example, while it's not possible with the Realtek driver.

 

[BeerBear]

It could be a foobar2000/Windows mixer getting stuck bug:
https://hydrogenaud.io/index.php?topic=119941.0
https://hydrogenaud.io/index.php?topic=119870.0
https://hydrogenaud.io/index.php?topic=121947.0

 

[Offler]

It could be a foobar2000/Windows mixer getting stuck bug:
https://hydrogenaud.io/index.php?topic=119941.0
https://hydrogenaud.io/index.php?topic=119870.0
https://hydrogenaud.io/index.php?topic=121947.0

Looks like it, Its present even in latest version of Foobar.

 

[edechamps]

I see lots of people in this thread are interested in inspecting the output of the Windows audio engine. I think you will be interested in what I just implemented in the latest release of FlexASIO:

WASAPI provides a feature called loopback recording, which makes it possible to capture whatever audio signal is being played through an output device. This feature is supported by PortAudio (and FlexASIO), which exposes it in the form of extra "virtual" input devices whose names end with [Loopback]. To record the audio flowing through a particular output device, simply use the corresponding loopback device. The signal is mirrored near the end of the Windows audio engine pipeline, after all APOs (including CAudioLimiter) but before conversion to integer.

This makes it possible to measure the output of the Windows audio engine on any device using REW for example, without the need to manually set up a loopback mechanism. Just set the backend to WASAPI, the output to the device you're interested in, the input to the corresponding [Loopback] device, and off you go.

 

[Aerith Gainsborough]

I see lots of people in this thread are interested in inspecting the output of the Windows audio engine. I think you will be interested in what I just implemented in the latest release of FlexASIO:



This makes it possible to measure the output of the Windows audio engine on any device using REW for example, without the need to manually set up a loopback mechanism. Just set the backend to WASAPI, the output to the device you're interested in, the input to the corresponding [Loopback] device, and off you go.

Neat functionality for easy "record what you hear". Cool!

Whether I resample or not. 0dB FS or -1dB FS, all harmonics are below -140dB in both 1K sine and 19+20K.
I can see no activity of the windows limiter whatsoever in the RTA. I do get the -0.1dB on the display of my RME though.
Tested with "primary sound driver" in foobar and smplayer, both RME and AVR via bog standard HDMI. Oo

 

[BeerBear]

The signal is mirrored near the end of the Windows audio engine pipeline, after all APOs (including CAudioLimiter) but before conversion to integer.

Do you know if dithering is used at that stage, before the stream is sent to hardware?
I suspect it isn't, which would make WASAPI shared also bit-perfect at max volume, just like WASAPI exclusive (assuming, of course, that it doesn't trigger the limiter or involve other processing).
It would be easy to check this with a digital recording (SPDIF...). Maybe the MQA light could give us a hint too, as discussed a few posts ago, but I'm not sure how reliable that is and I don't want to encourage anyone to spend money on that scam.

 

[edechamps]

Do you know if dithering is used at that stage, before the stream is sent to hardware?

It's easy to verify the presence of dithering using a virtual loopback audio device. I use Virtual Audio Cable which is well-suited to this kind of experiments.

I just did a few quick measurements and at first glance it looks like the Windows audio engine uses dithering when converting to 16-bit integer, but not when converting to 24-bit.

As for the WASAPI loopback feature, it doesn't seem to show any dithering, even when the device is set to 16-bit, leaving me to conclude that the mirroring occurs before dithering takes place.

It would be easy to check this with a digital recording (SPDIF...).

There's no need for that. Just use a virtual driver like Virtual Audio Cable. The free trial version works just fine and you don't need any hardware at all. VAC looks like real audio hardware as far as the Windows audio engine is concerned.

 

[Aerith Gainsborough]

which would make WASAPI shared also bit-perfect at max volume

WASAPI shared does not pass my RME's bit perfect test even at maximum volume.
It can't, due to CAudioLimiter altering the signal.

You have to use ASIO or exclusive to bypass it.

 

[edechamps]

I suspect it isn't, which would make WASAPI shared also bit-perfect at max volume, just like WASAPI exclusive (assuming, of course, that it doesn't trigger the limiter or involve other processing).

I did a quick experiment to try to confirm this. In REW, I configured the generator for a 997 Hz -10 dBFS sine and used the REW functionality to save the generator output to a 32-bit float WAV file. I then opened that WAV file in the RTA - basically using REW to analyse its own test signal, to act as a control/reference. And then in the same RTA window I analysed the same signal but this time being played through WASAPI loopback. The two traces pretty much line up on top of each other, suggesting that the Windows audio engine pipeline is either bit-perfect or very, very close (at least up to the loopback mirroring point):

In both cases SINAD is about 136 dB which sounds about right for 32-bit float (23-bit mantissa * 6).

If I do the same at 0 dBFS then CAudioLimiter rears its ugly head as expected:

at max volume

Volume doesn't really matter here, because Windows uses hardware volume control anyway for devices that support it (which is most of them). Meaning the master volume control for the device only affects the hardware volume control and has no effect on the bitstream flowing through the Windows audio engine. (Obviously this doesn't hold for per-app volume controls.)

WASAPI shared does not pass my RME's bit perfect test even at maximum volume.
It can't, due to CAudioLimiter altering the signal.

Right. I suspect it might pass such a test though as long as the test signal doesn't get loud enough to trigger the limiter.

 

[Aerith Gainsborough]

If I do the same at 0 dBFS then CAudioLimiter rears its ugly head as expected:

I'm confused. Why don't I get that?
When I set REW FlexASIO to input/output of the same sound device, say HDMI output to my AVR, I can go all the way to 0dBFS w/o the limiter kicking in.

 

[edechamps]

When I set REW FlexASIO to input/output of the same sound device, say HDMI output to my AVR, I can go all the way to 0dBFS w/o the limiter kicking in.

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

If your REW test signal is set to 0 dBFS, but it's being recorded at less than -0.15 dBFS, that most likely means your signal is going through some kind of volume control before the output of the Windows audio engine pipeline. (That's especially likely with something like HDMI which, AFAIK, is one of these rare audio drivers that leverage software volume control within the Windows audio engine.)

 

[Grooved]

I made a test with SPDIF IN and OUT, selecting both as default Input and Output for Windows, and unchecking exclusive mode
I played 1kHz 44.1kHz 24bit files (once 0dB and once -1dB) in Foobar (with full volume and "Default: primary sound driver" as output, and recorded in REW with both Java driver and ASIO4ALL with SPDIF IN selected.

For 0dB file, I had full level show in Windows sound window, and a bit less with -1dB file:

Here are the results in REW

0db Java driver:

0dB ASIO4ALL: not lower level (-0.13)

-1dB Java:

-1dB ASIO4ALL: perfect

 

[edechamps]

0db Java driver: the Windows Sound window shows full level, but REW shows -12.17dB, so maybe Windows is doing something after the input stage, and not on the output

Did you check the volume setting of the Windows input audio device? That would explain the discrepancies.

 

[Grooved]

Did you check the volume setting of the Windows input audio device? That would explain the discrepancies.

Oh... thanks
I don't know why it was set at 25 instead of 100, I never change that. Maybe I did during the previous test but I don't remember doing such a thing.

Found it: it when I launch REW, "Control input volume" in checked and set on 0.25, and even if I uncheck it, it leaves Windows setting at 25, so I need to adjust it to 100.
Maybe it's only with Java driver, I never use it, except now for this test.

I've edited the previous post.

Now, tried FLEXASIO in Directsound with SPDIF (I get the same result with HiFi Cable as digital internal loopback):
at -0.13dB:

at -0.14dB:

Still with FLEXASIO but with WASAPI and Exclusive mode in Windows settings (doesn't change anything if set both IN and OUT as Windows default devices or not)

at -0.13dB:

at -0.14dB:

And to compare with ASIO4ALL, at -1dB WASAPI: a bit more distorsion on H3, H5 and H7 with FLEXASIO, but less noise (-140.8 instead of -140.1)

 

[BeerBear]

There's no need for that. Just use a virtual driver like Virtual Audio Cable. The free trial version works just fine and you don't need any hardware at all. VAC looks like real audio hardware as far as the Windows audio engine is concerned.

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

WASAPI shared does not pass my RME's bit perfect test even at maximum volume.
It can't, due to CAudioLimiter altering the signal.

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.