Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Windows 7's resampling sucks (Read 90751 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Windows 7's resampling sucks

Reply #25
Couple of things...

It looks like foobar2000 implementation of WASAPI uses the exclusive mode. (it doesn't allow other apps to make sound when playing)
I've managed to implement the shared mode, and indeed I wasn't right. The documentation doesn't explicitely say that you cannot use another setting than the one returned to you by the call to GetMixFormat() (Ok, it says it in the page you pointed, but that's not explained in the interface definitions). On the other hand, at least the bitdepth is 32bit float.

In this case, you are right that an application using the shared mode would need to have a resampler if it wants to use multiple samplerates.


I also took the time to install rmaa6 and test this laptop's integrated soundcard with a loopback cable. The results I got are like yours, but I still think you exaggerated.
Having 16bit 44Khz in rmaa, 16bit 192Khz in speakers, and 16bit 44Khz in line in gives me the same graphic that you got (the one with smooth rolloff). If I use 16bit 44Khz -> 16bit 96Khz -> 16bit 44Khz, then the rolloff is still stronger, yet not by much more.

Having all three set to 16bit 44Khz in all doesn't give me as good a graphic than you, it is just partially better, and using 16bit 96Khz in all gives me a very nice response.
comparisons
96Khz

Windows 7's resampling sucks

Reply #26
Thank you for the update [JAZ] and my apologies for my sometimes harsh replies.

I extended RMAA's standard zoom setting to the right with interesting [a href='index.php?act=findpost&pid=743196']results[/a]. Are your's comparable, when you record with a higher sample rate?

The results somewhat confuse me. The 44.1->44.1 noise could be a DAC artifact. But why differ the other two curves the way they do, when 192-192kHz loopback works fine?


Windows 7's resampling sucks

Reply #27
The problem is mostly solved. It seems to be a really obscure bug. All analog 192 kHz output gets low-passed at 20 kHz unless you are concurrently recording at 192 kHz!!! That's right, pure 192 kHz playback - whatever you have locally set as recording sample rate - and captured by another computer will get a 20 kHz low-pass, but a local RMAA test will show a super-flat bandwidth of over 50 kHz. Since I almost exclusively used 44.1 kHz source signals in RMAA this almost drove me  . Sending a 192 kHz test signal to the second computer was a very desperate, last attempt (and finally eye opener). The HF roll-off is a result of low-passing twice, first by DirectSound and then again due to the bug.

The 44.1->44.1 and 44.1->96 modes only undergo no or just one (proper) resampling by DirectSound. And the quality is fine!

This makes the topic title misleading. I propose changing it to "How I got 0wn3d by a b1tch ca113d ALC889".

Windows 7's resampling sucks

Reply #28
The HF roll-off is a result of low-passing twice, first by DirectSound and then again due to the bug.

Why should DirectSound do 20kHz lowpass-filtering if you're using 192kHz sample rate on the output?
Your signal will imho be lowpass-filtered twice, once in the output stage at around 40-50kHz (if your codec is good) and once in the input stage at 20kHz (recording at 44.1kHz). If this bug is really hardware (or driver) related the codec (dac side) is lowpass-filtering at 20kHz. I have no idea why this should be the case.

Windows 7's resampling sucks

Reply #29
Why should DirectSound do 20kHz lowpass-filtering if you're using 192kHz sample rate on the output?


Because the application outputs a 44.1 kHz stream. It's a side effect of upsampling.

Your signal will imho be lowpass-filtered twice, once in the output stage at around 40-50kHz (if your codec is good) and once in the input stage at 20kHz (recording at 44.1kHz).


The full chain is actually something like this:

Application (44.1 kHz) -> SRC (192 kHz) [LP@~22 kHz] -> DAC (oversampling to 192*n kHz) [1. digital LP@~96 kHz, 2. analog LP@~192*n/2 kHz] -> ADC [1. analog LP@~96*n/2 kHz, 2. digital LP@~48 kHz] -> Audacity (96 kHz)

Windows 7's resampling sucks

Reply #30
Maybe we can get an additional confirmation? Personally, I would also scratch my head if I read this. The culprit is an ALC889 on an Intel DP55WG mobo.

PS Or the culprit is RMAA. I'm going to check this next.

Windows 7's resampling sucks

Reply #31
Maybe we can get an additional confirmation? Personally, I would also scratch my head if I read this. The culprit is an ALC889 on an Intel DP55WG mobo.

Datasheets are available. I'm looking into it atm.
edit: ALC889 Datasheet (mirror 1 from realtek page)

Windows 7's resampling sucks

Reply #32
Full stop. It was just RMAA that fucked up. And with it I did ofc. I should not have relied on a single tool. When I playback and capture white noise manually wit Audacity, everything works as expected at all sample rates, including 192 kHz. There is no 20 kHz low-passing at 192 kHz. It is just RMAA that behaves strangely at 192 kHz with the ALC889. At 96 kHz and below it measures full-spectrum. Set to output 192 kHz in non-loop-back mode it falls back to just 20 kHz bandwidth. But in loop-back mode it tests the whole 96 kHz bandwidth. Next I will try to reproduce the HF roll-off manually with Audacity. Maybe that was also just RMAA.

PS I also cannot reproduce the 44.1->192kHz roll-off with Audacity.

For the record: Windows 7's resampling is fine!

Windows 7's resampling sucks

Reply #33
Full stop. It was just RMAA that fucked up. And with it I did ofc. I should not have relied on a single tool. When I playback and capture white noise manually wit Audacity, everything works as expected at all sample rates, including 192 kHz. There is no 20 kHz low-passing at 192 kHz. It is just RMAA that behaves strangely at 192 kHz with the ALC889. At 96 kHz and below it measures full-spectrum. Set to output 192 kHz in non-loop-back mode it falls back to just 20 kHz bandwidth. But in loop-back mode it tests the whole 96 kHz bandwidth. Next I will try to reproduce the HF roll-off manually with Audacity. Maybe that was also just RMAA.

PS I also cannot reproduce the 44.1->192kHz roll-off with Audacity.

For the record: Windows 7's resampling is fine!
Actually, that´s a relief. Then it´s true what they wrote when they presented the new engine: it has improved. Maybe RMAA has problems with onboard codecs...    I once did a test with my onboard VIA VT1708s and also found that it couldn´t process 192 kHz despite it being advertised as being able. But then, maybe it´s RMAA. When I tested my ASUS Xonar Essence ST with an analogue loopback, RMAA gave me a perfectly flat response for all sample rates with +/- 0.2 dB. Out of curiosity I tested the same with pink noise generated by AudioDiffMaker - which gave me a + 1.5 dB bump at lower frequencies combined with a soft rolloff at higher frequencies starting at 10 kHz reaching -2 dB at 20 kHz. I still don´t know which one of the programs measured incorrect.
marlene-d.blogspot.com

Windows 7's resampling sucks

Reply #34
What about your initial suspicion about muffled sound?

I couldn't longer ignore the impression that the resampled output sounded somewhat muffled and did some measurements.



Windows 7's resampling sucks

Reply #36
Googlebot,

This thread was actually helpful, in that it forced me to look at my Foobar wasapi setup, which I had done incorrectly.  I had been under the impression that FB wasapi was shared mode, but it is indeed exclusive.  Switching back and forth between Speakers and wasapi as fast as I can click, I don't really hear a difference, but at least I know how to force exclusive mode now.

Windows 7's resampling sucks

Reply #37
http://blogs.msdn.com/b/matthew_van_eerde/...-pull-mode.aspx
http://blogs.msdn.com/b/matthew_van_eerde/...t-you-hear.aspx

Is it possible to test Vista/Win7 SRC quality with this small app? If yes, then 192->44.1kHz or 44.1->192kHz SRC isn't that bad...



How exactly was this Adobe Audition plot made?
What was the source sweep file derived from?
What Play and Record applications were used?
I am curious about the complete procedure used here.

I am in the process of analyzing and documenting Windows SRC performance between Windows XP and Windows Vista/7. It seems as though Windows Vista/7 Record SRC using emulation mode is a problem. Play seems fine. Most Windows applications are still using Wave emulation mode, and unless the target hardware sample rates are respected, Windows Vista/7 will do a pretty horrible job of SRC in Record. This is not true of XP. I have tried to contact Microsoft numerous times regarding this, but they are apparently not available for comment.

The best way I've found to test this is to use VAC, eliminating any possible hardware driver problems.

Windows 7's resampling sucks

Reply #38
This area has also my interest, however the problem are non-existent sources,tests or other material about it. I'm still unclear in two things i've written earlier in HA about (this or other threads, don't know yet).

1. MF pipeline uses under its audio DSPs a resampler DMO, which can be used by developing audio apps and its accuracy (filter length) can be adjusted from 1 to 60 (default is 30). Don't know if this can be also adjusted with "normal" playback through e.g. WMP12, as this is to me the only known MF application.

2. I suppose this component isn't used for resampling when using other APIs, e.g. dsound, waveout, xaudio2 (Tuniac uses this "dsound" replacement for hardware acceleration under xp - this seems not to be the case with WV/7 however, but i'm not sure). But if this is true, where does the resampling take place in this case? In the APIs themselves or in mixing engine Audiodg.dll? And can the accuracy also be adjusted (under V/7)? Under XP this was possible, but there was another architecture and the resampling was probably situated in kmixer.sys

However i don't use JRMC, i've used it once to find out the resampler DMO precision, because it allowed me to include it into the audio path, not as DSP (all were disabled), but in file type handling it was possible to "pin" it to specified format, e.g. wav. Of course, disk writer was used for output.
As audio driver was hard-settled to 16/48, resampler DMO automatically processed audio to these values (so bit dither/bitreduction was applied also). As usual, swept24 (24/96) from here: http://src.infinitewave.ca/TestSignals.zip was used for resampling.
The result is here: http://img571.imageshack.us/i/1648b.gif
Maybe this is with the default setting (30), don't know as adjusting wasn't possible in JRMC.

Windows 7's resampling sucks

Reply #39
How exactly was this Adobe Audition plot made?

Select the whole audio, press Alt+Z, press "Scan Selection".

What was the source sweep file derived from?

IIRC it was just a pulse train.

What Play and Record applications were used?

Play: silence.exe + foobar2000 with DirectSound output.
Record: loopback-capture.exe

Windows 7's resampling sucks

Reply #40
How exactly was this Adobe Audition plot made?

Select the whole audio, press Alt+Z, press "Scan Selection".

What was the source sweep file derived from?

IIRC it was just a pulse train.

What Play and Record applications were used?

Play: silence.exe + foobar2000 with DirectSound output.
Record: loopback-capture.exe


Any chance you can make the pulse train file available?
I would like to duplicate the results here.


Windows 7's resampling sucks

Reply #42
Playback over WASAPI must match the sample rate of the output device. Thus applications must supply their own resampling if the playback rate does not match. Most applications don't do this but just employ MME or DirectSound, which provide transparent resampling for non-matching rates.

Since some of my content is 44.1 kHz and some 48 kHz I used to set the output rate to 192 kHz so that all audio had to be upsampled. With good software resampling and a cheap onboard codec this could, in theory, even improve the overall result. But the opposite was true. Today I couldn't longer ignore the impression that the resampled output sounded somewhat muffled and did some measurements.

You can view the result [a href='index.php?showtopic=86675']here[/a]. The upsampled output (44.1 -> 192 kHz) suffers from quite a HF roll-off in comparison to pure 44.1 kHz output.

In Windows XP the SRC quality could be adjusted. I can't find anything comparable in Windows 7. Does anyone know more?


I was having this same problem.  The speeds weren't matching up or sinking.  I was having trouble with muffling audio too.  Especially when I listened to it on my home theater system speakers.  I found that I was able to swap from using the motherboard sound to my other card and now I can get WASAPI to run at 44.1k without resampling.  I don't know if that will help you at all with your audio.  I don't know if that helped your or not, or will just confuse you.

 

Windows 7's resampling sucks

Reply #44
from the abovementioned thread:
Quote
Media Foundation, DirectShow, DirectSound, and waveOut each do sample rate conversion slightly differently.  There is a bug in the waveOut sample rate conversion which results in a lower-quality sample rate conversion than was done in XP.

Windows 7's resampling sucks

Reply #45
Have you done any measurements on XP to confirm that there's a regression in Win 7.


XP and Vista (and I believe W7) are so dissimilar that there is no means to compare them. One is fixed, one is float, one uses a polynomial resampler, the other a dedicated, high-quality resampler (unless you provide many, many inputs in which case it will drop the quality due to the demand on the CPU).

That is, if you use new, rather than legacy, system inputs.
-----
J. D. (jj) Johnston

Windows 7's resampling sucks

Reply #46
Media Foundation, DirectShow, DirectSound, and waveOut each do sample rate conversion slightly differently.

I had to read that a few times before realizing that the majority of my audio & audio/video listening is done through DirectShow apps.  Do we know when waveOut is invoked? Is the problem only in 41<-->48 SRC or others?

Windows 7's resampling sucks

Reply #47
http://blog.szynalski.com/2009/11/17/an-au...-7/#comment-592

Quote
I generated a 40 Hz tone in Cool Edit Pro, both in 44.1 kHz and 48 kHz. Whenever the sample rate doesn’t match the Windows sample rate, I hear the same high-frequency distortion artifact.

Here are the results of playing a 44.1 kHz WAV file (40 Hz tone) in various apps with the Windows sample rate set to 48 kHz:

Cool Edit Pro 2.0 – distortion
Windows Media Player – no distortion
Foobar2000 – no distortion
iTunes 7 – no distortion
Winamp (with Directsound output) – no distortion
Winamp (WaveOut output) – distortion

In short, Directsound output upsamples correctly. WaveOut produces distortion.


I also tested 48 kHz WAV file and 44.1 Windows samplerate: waveout downsamples incorrectly too.

Windows 7's resampling sucks

Reply #48
I just checked the optional updates available for my Win 7 installation. No sign of a SRC update. Instead, they offer e.g. a "blurry font fix" to the IE 9 font rendering with highly questionable results.
[attachment=6741:ie9_blurry_font.png]

What an interesting choice of priority. No, actually it's not interesting, it's sad.

Chris
If I don't reply to your reply, it means I agree with you.

Windows 7's resampling sucks

Reply #49
I'm afraid audio has priority zero at Microsoft
Likewise both OSX and Linux have native USB audio class 2 drivers from mid 2010 on.
Nobody knows if MS even have plans to implement this.
TheWellTemperedComputer.com