• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Aerith Gainsborough

Addicted to Fun and Learning
Joined
May 4, 2020
Messages
853
Likes
1,280
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!)
20220505_143235_result.png


ASIO (Madiface driver)
20220505_143250_result.png
 

Offler

Senior Member
Joined
May 27, 2021
Messages
414
Likes
399
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
fooDEF.png


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


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


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

Addicted to Fun and Learning
Joined
Feb 26, 2021
Messages
679
Likes
441
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

Addicted to Fun and Learning
Joined
May 4, 2020
Messages
853
Likes
1,280
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

Active Member
Joined
Mar 9, 2020
Messages
264
Likes
252
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

Addicted to Fun and Learning
Joined
Feb 26, 2021
Messages
679
Likes
441
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.
 
Last edited:

edechamps

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
910
Likes
3,620
Location
London, United Kingdom
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

Addicted to Fun and Learning
Joined
May 4, 2020
Messages
853
Likes
1,280
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

Active Member
Joined
Mar 9, 2020
Messages
264
Likes
252
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

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
910
Likes
3,620
Location
London, United Kingdom
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

Addicted to Fun and Learning
Joined
May 4, 2020
Messages
853
Likes
1,280
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

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
910
Likes
3,620
Location
London, United Kingdom
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):

Screenshot 2022-05-07 150601.png


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:

Screenshot 2022-05-07 150756.png


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.
 
Last edited:

Aerith Gainsborough

Addicted to Fun and Learning
Joined
May 4, 2020
Messages
853
Likes
1,280
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

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
910
Likes
3,620
Location
London, United Kingdom
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

Addicted to Fun and Learning
Joined
Feb 26, 2021
Messages
679
Likes
441
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:
Windows 0dB SPDIF IN.PNG
Windows -1dB SPDIF IN.PNG


Here are the results in REW

0db Java driver:
Foobar Default Windows (SPDIF OUT default, non-exclusive) 1kHz 0dB 24bit to REW JAVA SPDIF IN.PNG



0dB ASIO4ALL: not lower level (-0.13)
Foobar Default Windows (SPDIF OUT default, non-exclusive) 1kHz 0dB 24bit to REW ASIO4ALL SPDIF...PNG


-1dB Java:
Foobar Default Windows (SPDIF OUT default, non-exclusive) 1kHz -1dB 24bit to REW JAVA SPDIF IN.PNG


-1dB ASIO4ALL: perfect
Foobar Default Windows (SPDIF OUT default, non-exclusive) 1kHz -1dB 24bit to REW ASIO4ALL SPDI...PNG
 
Last edited:

edechamps

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
910
Likes
3,620
Location
London, United Kingdom
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

Addicted to Fun and Learning
Joined
Feb 26, 2021
Messages
679
Likes
441
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:
FlexASIO Directsound both SPDIF IN and OUT as default -0.13dB.PNG


at -0.14dB:
FlexASIO Directsound both SPDIF IN and OUT as default -0.14dB.PNG



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:
FlexASIO WASAPI Exclusive both SPDIF IN and OUT as default -0.13dB.PNG


at -0.14dB:
FlexASIO WASAPI Exclusive both SPDIF IN and OUT as default -0.14dB.PNG


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)
FlexASIO WASAPI Exclusive both SPDIF IN and OUT as default -1dB.PNG
 
Last edited:

BeerBear

Active Member
Joined
Mar 9, 2020
Messages
264
Likes
252
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.
 
Last edited:
Top Bottom