Ending the Windows Audio Quality Debate

[Bergante]

Anyway audio is a second class citizen in Windows. I am still puzzled you need to add something external such as ASIO in order to have proper multitrack audio.

Insane!

 

[BeerBear]

you need to add something external such as ASIO in order to have proper multitrack audio.

What do you mean? Multitrack audio works just fine without ASIO from what I see.

The only major gripe I have with Windows is that there isn't a good low latency mode. That's why ASIO is still needed.

 

[Davide]

I currently get these two different results with Foobar 1.6.11, set with default output driver (WASAPI Shared should be).
Same difference appears with Audacity as recorder (but not as player) so it's not a REW bug.
Of course I checked the signal files to be sure they were correct, and they are.
I'm attaching them so you can try it too.

STEREO WHITE NOISE SIGNAL @ -12dBFS
(REW RTA measure Left channel)

MONO WHITE NOISE SIGNAL @ -12dBFS

This explanation on HA seems plausible.

 

[Bergante]

What do you mean? Multitrack audio works just fine without ASIO from what I see.

The only major gripe I have with Windows is that there isn't a good low latency mode. That's why ASIO is still needed.

I must be confused. So, can you use a multitrack USB class compliant audio device without a driver?

Still, why isn't there a low latency mode? Are they scanning audio with AV or something? lol

 

[edechamps]

So, can you use a multitrack USB class compliant audio device without a driver?

It took them a while, but Microsoft did add native support for USB Audio Class 2 in Windows 10, release 1703 (6 years ago). This means you don't need a third-party driver to use USB Audio Class 2 devices. I use the Microsoft driver to play 5.1 through my Asus Xonar U7 and it works just fine.

Still, why isn't there a low latency mode? Are they scanning audio with AV or something? lol

WASAPI Exclusive should provide latencies similar to ASIO, at least in theory. I suspect the reason why that's not always the case in practice is because both applications and manufacturers tend to focus on the ASIO latency because that's what people use and care about, with the WDM path left comparatively less optimized.

 

[Offler]

I was doing more loopback tests in Windows and noticed a weird thing that I can't explain.
With Audacity I play mono 44.1/16 WAV files with white noise and analyze the loopback in REW RTA through VB Hi-Fi Cable.
ALL, and I mean ALL, the volumes are set to 100%, including those relating to the Windows mixer (yes, all those dozens of adjustments that Windows integrates for no reason).
Yet if in Audacity I set the WASAPI driver instead of MME or DS, in REW I measure about -1 dBFS RMS less.
The strange thing is that if I play a 1kHz tone at a fixed level, there is no such difference.
I also installed Eq APO to bypass hidden APOs, but nothing changes. And I have seen that it works both with DS, MME and WASAPI (if I apply with -6dB of attenuation for example, I detect it with all used drivers).
Also, similar issue with Foobar. All 100%, yet the Foobar level is -6 dBFS or so. And there is no ReplyGain set (verified).

WHY?!

MME DRIVER


Don't look at the scales of the axis because they are incorrect. I had set RTA wrong, but the level analysis window is correct, as well as the spectrum shown.

Been doing similar tests on Realtek 1220A connected to NAD 3020d V2 over TOSLINK.

1. There was little to no difference between Exclusive and ASIO modes of the driver.
FFTs were identical without any distortion caused by Windows.

2. Foobar with WASAPI Shared does deduce 6db + there is a bug mentioned above. Switched it to Exclusive.

3. When in Shared mode two synthetic 17.5KHz and 18KHz signals might cause distortion if the total peak gain in EAPO was above -6.3dB
For any other scenario, peak gain of -0.14dB was enough to avoid triggering distortion.

4. 192KHz 24bit in shared mode is ideal to avoid IMD
When playing 44KHz or 48KHz source signals over 44, 48 or 96Khz output in WASAPI Shared driver, there was always IMD introduced.

Worst case scenario was 48KHz signal played over 44KHz output.

Here are 17,5KHz and 18KHz signals generated as 44.1KHz played over 48Khz 24bit default format

On 192KHz 24bit there were two peaks caused by changing samplerate, but both were above 20Khz - there is no way to hear them.

Here are 17,5KHz and 18KHz signals generated at 44.1KHz played over 192Khz 24bit default format

and for control here is 44.1 "file" over 44.1 output without any sampling conversion:

For gaming i use 192Khz 24bit output, with -6.3 gain in EAPO and little bit more volume on physical amplifier.

For serious listening I use WASAPI Exclusive mode, which simple transports data to external DAC without any alteration.

 

[Davide]

Here are 17,5KHz and 18KHz signals generated at 44.1KHz played over 192Khz 24bit default format

I find different results with VB Cable HiFi ASIO Bridge set to 192/24.
How do you capture the loopback after Windows mixer?
I'm afraid you are not measuring the effect of Windows resampling but something else.
That noise floor doesn't look like a digital measurement to me.
I think you are confusing something...
Also, that distortion you show is not IMD, HD at best. IMD should be symmetrical.

Right away, you can see the effect of Windows resampling 44.1 to 192. In the 1st case you can clearly see the effects of the Windows limiter, while in 2nd one nothing when it is not triggered.

Foobar WASAPI Shared playing dual tone 17.5kHz + 18 kHz, -3.01dBFS RMS (0 dBFS Peak), 44.1kHz 16bit dithered

Foobar WASAPI Shared playing dual tone 17.5kHz + 18 kHz, -20dBFS RMS, 44.1kHz 16bit dithered

Spectrogram of -3.01dBFS RMS test signal

I showed in my previous post the quality of Windows upsampling 44.1 to 192 and it's trasparent.

For the record, Foobar produce higher noise floor than that contained in the signal (pay attention).
I don't know what could be the reason... evidently it's not so bit perfect.

And by the way, WASAPI Exclusive mode isn't always bit perfect. See Amazon Music players. Resampling can occur.

 

[edechamps]

And by the way, WASAPI Exclusive mode isn't always bit perfect. See Amazon Music players. Resampling can occur.

I would be extremely surprised if WASAPI Exclusive resampled the signal - it's supposed to provide direct access to the DAC's hardware buffers with nothing in-between. What is more likely is that the application decides to resample by itself before handing off the signal to WASAPI. In which case it's a unfair to blame WASAPI Exclusive for this behaviour - if the application decides to silently resample then it's the application's fault, not WASAPI's.

 

[Davide]

I would be extremely surprised if WASAPI Exclusive resampled the signal - it's supposed to provide direct access to the DAC's hardware buffers with nothing in-between. What is more likely is that the application decides to resample by itself before handing off the signal to WASAPI. In which case it's a unfair to blame WASAPI Exclusive for this behaviour - if the application decides to silently resample then it's the application's fault, not WASAPI's.

It could also be the Amazon Music application that does the resampling, but it seems strange to me that it decides to stream a track at, example, 96/24 (seen in the stats) and then resampling it to match WASAPI format, instead of change the WASAPI sample rate.

 

[edechamps]

It could also be the Amazon Music application that does the resampling, but it seems strange to me that it decides to stream a track at, example, 96/24 (seen in the stats) and then resampling it to match mixer format.

You can check how the application is using WASAPI using the most excellent API Monitor. Make sure to capture "Audio and Video", start the capture, make the application play some audio, then look for the last successful IAudioClient::Initialize call. Besides exclusive mode being apparent from the AUDCLNT_SHAREMODE_EXCLUSIVE parameter, you can dig into the Format parameter and will find the sample rate under nSamplesPerSec. This is the sample rate of the signal that the application is handing off to WASAPI.

Here's an example capturing REW's WASAPI Exclusive calls:

 

[Davide]

You can check how the application is using WASAPI using the most excellent API Monitor. Make sure to capture "Audio and Video", start the capture, make the application play some audio, then look for the last successful IAudioClient::Initialize call. Besides exclusive mode being apparent from the AUDCLNT_SHAREMODE_EXCLUSIVE parameter, you can dig into the Format parameter and will find the sample rate under nSamplesPerSec. This is the sample rate of the signal that the application is handing off to WASAPI.

Here's an example capturing REW's WASAPI Exclusive calls:

View attachment 299196

I try as soon as I can, for sure. Thanks a lot for the suggestion. Fantastic tool!

For info, what entry appears when WASAPI SHARED is called?

 

[Atanasi]

I try as soon as I can, for sure. Thanks a lot for the suggestion. Fantastic tool!

For info, what entry appears when WASAPI SHARED is called?

AUDCLNT_SHAREMODE_SHARED

 

[Davide]

AUDCLNT_SHAREMODE_SHARED

Thanks.

Meanwhile, for the completeness of the measurements concerning the Windows resampler passing from 44.1 to 192, given the slope of the LPF filter shown in my previous graphs, I wanted to verify the amount of pre-ringing introduced.
Below are the results (blue) compared to no resampling (orange).
As you can see, it is symmetric, so linear phase / FIR filter.

Is it audible? I don't know...

It would appear that the pulse oscillates at a frequency of 50us so 20kHz if I have not miscalculated. Note that 20kHz is not the ringing audio frequency, but the frequency at which the pulse increases and decreases in intensity. The related audio content I don't know how to verify it. Maybe it is sufficient to window that part... I'll try.

 

[Davide]

Thanks.

Meanwhile, for the completeness of the measurements concerning the Windows resampler passing from 44.1 to 192, given the slope of the LPF filter shown in my previous graphs, I wanted to verify the amount of pre-ringing introduced.
Below are the results (blue) compared to no resampling (orange).
As you can see, it is symmetric, so linear phase / FIR filter.

Is it audible? I don't know...

It would appear that the pulse oscillates at a frequency of 50us so 20kHz if I have not miscalculated. Note that 20kHz is not the ringing audio frequency, but the frequency at which the pulse increases and decreases in intensity. The related audio content I don't know how to verify it. Maybe it is sufficient to window that part... I'll try.

Ok, I windowed the pre-ringing part and the resulted FR (green) and phase (purple) is this.

Don't know if it makes sense...

 

[danadam]

Ok, I windowed the pre-ringing part and the resulted FR (green) and phase (purple) is this.

Don't know if it makes sense...

If what makes sense? The green FR? Yes, with square window the waveform has an abrupt end on the right side, so more or less all frequencies are expected.

 

[Davide]

If what makes sense? The green FR? Yes, with square window the waveform has an abrupt end on the right side, so more or less all frequencies are expected.

I'm not sure if that plot has some meaning in practice.
Maybe a waterfall graph better represents how is happening in the preringing region, in audibility terms.

 

[danadam]

in audibility terms.

Haven't you already concluded earlier that the resampler is inaudible?

 

[Davide]

Haven't you already concluded earlier that the resampler is inaudible?

I have. Maybe I'm expressing myself badly in English. Currently I'm saying that the graph of FR and phase alone perhaps doesn't fully represent what happens in the pre-ringing window I set, as it doesn't show the trend of magnitude over time.
About audibility of that ringing in time domain, I said that I don't know... I suspect it's not audible. But I'm just trying to best represent that to leave you some considerations.

 

[danadam]

Currently I'm saying that the graph of FR and phase alone perhaps doesn't fully represent what happens in the pre-ringing window I set, as it doesn't show the trend of magnitude over time.

Yes, I don't think I understand what you mean What did you expect to see if it did represent this?

You could always use some smooth window instead of square one. You'll probably get something like this:

That's impulse response from "sox rate" command and spectrum is using Hahn window. This is 2K FFT and preringing.flac consists of 2K samples.

Not sure if it helps with anything

 

[Alexey Lukin]

STATS OF ORIGINAL TEST SIGNAL (RANDOM WHITE NOISE FULL BAND MONO 44.1kHz 16bit DITHERED, GENERATED WITH REW)
View attachment 298951

STATS OF SIGNAL UPSAMPLED AND DITHERED WITH IZOTOPE RX 10
View attachment 298952
Let me say I cannot figure out why iZotope predicted true peaks differ so much, especially compared to the original signal... but this is another matter.

The cause of this difference is in oversampling filters. The standard for computing true peaks suggests using this 4x filter, with noticeable ripple and early roll-off.

iZotope resampler is using steeper filters with flat passband, so it can produce a different overshoot on the same test signal.