Bergante
Member
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!
Insane!
What do you mean? Multitrack audio works just fine without ASIO from what I see.you need to add something external such as ASIO in order to have proper multitrack audio.
I must be confused. So, can you use a multitrack USB class compliant audio device without a driver?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.
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
Been doing similar tests on Realtek 1220A connected to NAD 3020d V2 over TOSLINK.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.
Here are 17,5KHz and 18KHz signals generated at 44.1KHz played over 192Khz 24bit default format
And by the way, WASAPI Exclusive mode isn't always bit perfect. See Amazon Music players. Resampling can occur.
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.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 mixer format.
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.I try as soon as I can, for sure. Thanks a lot for the suggestion. Fantastic tool!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 successfulIAudioClient::Initialize
call. Besides exclusive mode being apparent from theAUDCLNT_SHAREMODE_EXCLUSIVE
parameter, you can dig into theFormat
parameter and will find the sample rate undernSamplesPerSec
. 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?
AUDCLNT_SHAREMODE_SHARED
Thanks.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.
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.Ok, I windowed the pre-ringing part and the resulted FR (green) and phase (purple) is this.
Don't know if it makes sense...
I'm not sure if that plot has some meaning in practice.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 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.Haven't you already concluded earlier that the resampler is inaudible?
Yes, I don't think I understand what you mean What did you expect to see if it did represent this?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.
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.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.