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.comparisons96Khz

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".

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.

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.

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.

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.

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.

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.gifMaybe this is with the default setting (30), don't know as adjusting wasn't possible in JRMC.

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 here. 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.

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.

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).

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?

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.

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