Ending the Windows Audio Quality Debate

[Davide]

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.

But... are you the Alexey Lukin of iZotope?!

However, I suspected that.
But given the very high upsampling frequencies of modern DACs, and given the lower peaks that are found with x4 upsampling (1 dB more or less), isn't that foretold datum useless or misleading?

I take the opportunity to ask you something. What bit depth does the resampler work at? Is it necessary to apply dither after resampling?
I applied the dither to that resampled file because I have the doubt that resampler increase bit depth to carry out the work.

 

[Alexey Lukin]

True peaks are not intended to be completely accurate predictions of DAC peaks, because every DAC has its own filters. Some even use minimum-phase filters which can peak more than linear-phase ones. That's why you often see -1 or -2 dBTP requirements in broadcast, not 0.
The practical importance of true peaks is to raise awareness of intersample clipping and establish some protections, without excessive cost of long filters or high oversampling.

Resamplers, like any filters, always increase the bit depth of the signal. RX's resampler operates internally in 64 bits and outputs the file in 32-bit float format, which is RX's internal storage format. If your original file has a lesser resolution, then it should be dithered — either manually with Dither module or automatically upon saving.

Yes, I'm from iZotope.

 

[Davide]

Yes, I'm from iZotope.

First of all, welcome to the forum!
Glad to have another industry insider.
It is an honor to be able to speak with you, and it is pleasant that you have joined the discussion. Thanks for that.
Furthermore, congrats for the development of the RX suite.

Anyway, thanks for the reply.
Glad to know I did it right.

As for TP detection, surely variables are multiple and unpredictable, therefore margin is needed. It just amazes me so much difference (>1dB) between a x4 upsampling (suggested as a minimum value by ITU 1770) and higher values.
If I target -1dBTP of headroom, as often recommended, it could clip easily in the DAC...

 

[Offler]

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.

It was measured from the integrated amplifier's headphones jack, as I was testing it end-to-end.

There were some bogus claims that external DAC miraculously solves these problems, while people were unaware this is happenning at SW level in PC + I was testing how resampling affect listening experience according to the LTT graphs. 192KHz 24bit is simply the best and easiest to achieve scenario for most situations.

In the tests the limiter isnt kicking in, both signals are at -6.3dB from EAPO.

 

[Offler]

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.

Been testing WASAPI Exclusive and ASIO for Realtek1220. Results were perfectly identical, plus I checked the endpoints.

Incoming data stream was rendered at its original sample rate, the only thing that driver changed in the output is that it used 32bit(padded) format - eg. it was 24bits of data and 8bits of zeroes, which were cut away when transported to TOSLINK from the audio buffer.

Long story short - they were lazy at Realtek and decided to use 32bit buffer size for each sample, no matter what, while the excess data from lower bitrates are truncated upon rendering.

Media Player classic for example might put its own Volume Mixer into render chain, but upon checking how the sound is rendered, its listed what type of filters were used in the render.

 

[Davide]

It was measured from the integrated amplifier's headphones jack, as I was testing it end-to-end.

There were some bogus claims that external DAC miraculously solves these problems, while people were unaware this is happenning at SW level in PC + I was testing how resampling affect listening experience according to the LTT graphs. 192KHz 24bit is simply the best and easiest to achieve scenario for most situations.

In the tests the limiter isnt kicking in, both signals are at -6.3dB from EAPO.

Your measurement chain is not very suitable to test the Windows resampler effect in my opinion.
Mine indisputably is, and those two tones upsampled to 192 by Windows don't produce the distortion you're seeing.
It must be caused by something else: Realtek drivers, hidden APOs, your DAC... for example.

PS. Or different Windows version.

 

[BeerBear]

Right away, you can see the effect of Windows resampling 44.1 to 192...
Foobar WASAPI Shared playing...

As I said before, Foobar performs its own resampling. So you can't use it to test Windows' resampling.
It also has a console (View -> Console) which shows some information about what it's doing.

 

[Alexey Lukin]

It just amazes me so much difference (>1dB) between a x4 upsampling (suggested as a minimum value by ITU 1770) and higher values.
If I target -1dBTP of headroom, as often recommended, it could clip easily in the DAC...

If you choose a lower filter steepness for upsampling, like S = 5 in RX, your true peak levels may actually decrease after upsampling of white noise. So, it really depends on the filter, with steeper filters having more potential for overshoot.
As to the DAC clipping — 1 dB of headroom will probably eliminate 99% of all clipping, and the remaining 1% will be reduced by 1 dB, so it should be harmless.

 

[Yasuo]

Do these options affect the sound quality?

Can't seem to find any documentation about them.

 

[edechamps]

Do these options affect the sound quality?

No. Their only purpose is to help with driver compatibility (sometimes).

Can't seem to find any documentation about them.

There is some information on these concepts in my APO notes.

 

[witwald]

True peaks are not intended to be completely accurate predictions of DAC peaks, because every DAC has its own filters. Some even use minimum-phase filters which can peak more than linear-phase ones. That's why you often see -1 or -2 dBTP requirements in broadcast, not 0.

Hi. Can you provide a concrete, reproducible example of what you describe above? That would be helpful for me to gain a better understanding of the problem. I expect that there are some "torture test" signals that will trigger the issue.

 

[Alexey Lukin]

Hi. Can you provide a concrete, reproducible example of what you describe above?

It really happens on most files, but here's one particular example. Generate a 10-second file with white noise at 44.1 kHz. Measure true peak levels. Upsample the file to 176.4 kHz using various upsamplers and measure true peak levels again. You'll observe that true peaks of the upsampled file differ from true peaks of the original file and depend on steepness of the upsampling filter. I've done my experiments in iZotope RX, but feel free to use other software.

 

[pkane]

Hi. Can you provide a concrete, reproducible example of what you describe above? That would be helpful for me to gain a better understanding of the problem. I expect that there are some "torture test" signals that will trigger the issue.

Intersample overs are not limited to different filters, but can affect any PCM sampled or resampled audio stream where samples come within a few dB of 0dBFS. Here's an example using one of the three different intersample-over torture signals supplied with Multitone app. You can see that while actual samples are not exceeding 0dBFS (red), the waveform peaks are well above this level (blue):

 

[Alexey Lukin]

The worst "torture signal" for intersample peaks is a sequence [... +1 −1 +1 −1 +1 −1 +1 +1 −1 +1 −1 +1 −1 +1 ...] (note two "+" samples in the middle). Although it is completely synthetic and unlike any realistic signal, it can produce up to infinite dB overshoot with sufficiently steep upsampling filters.

 

[pkane]

The worst "torture signal" for intersample peaks is a sequence [... +1 −1 +1 −1 +1 −1 +1 +1 −1 +1 −1 +1 −1 +1 ...] (note two "+" samples in the middle). Although it is completely synthetic and unlike any realistic signal, it can produce up to infinite dB overshoot with sufficiently steep upsampling filters.

More "realistic" tests included in Multitone are from an AES paper, 0dBFS+ Levels in Digital Mastering by Nielsen and Lund. Here's a quote:

3.1 Phase and Level

The synchronously sampled sine waves were generated with two start phases: One with the theoretical
maximum value present as a sample value in the digital domain and one with the highest possible analog
peak level within the limitation of +/-1 in the digital domain.

5512.5 Hz: 90 and 67.5°. At 67.5° the analog peak level is up to +0.69 dBFS.
7350 Hz: 90 and 60°. At 60° the analog peak level is up to +1.25 dBFS.
11025 Hz: 90 and 45°. At 45° the analog peak level is up to +3.0 dBFS.

 

[Alexey Lukin]

Yes, the 11 kHz sine wave is a classic example. Another interesting example is a white noise with binary distribution (i.e. all samples are either +1 or −1). It sounds like regular white noise, but has intersample peaks that are roughly +6 dB above digital values.

 

[Yasuo]

No. Their only purpose is to help with driver compatibility (sometimes).



There is some information on these concepts in my APO notes.

Thank you!

 

[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 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?

 

[Davide]

As I said before, Foobar performs its own resampling. So you can't use it to test Windows' resampling.
It also has a console (View -> Console) which shows some information about what it's doing.

Hell, I didn't notice the background resampling even though there was no DSP.
I tried with Jriver in WASAPI Shared but it says error, can't play 44.1 on device set to 192.
The only player that seems to work, leaving WASAPI to resample, is the REW generator.
Can you point me to another one?

 

[danadam]

The worst "torture signal" for intersample peaks is a sequence [... +1 −1 +1 −1 +1 −1 +1 +1 −1 +1 −1 +1 −1 +1 ...] (note two "+" samples in the middle). Although it is completely synthetic and unlike any realistic signal, it can produce up to infinite dB overshoot with sufficiently steep upsampling filters.

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