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 also don't think -1 dB at 17 kHz and -3 dB at 18.25 kHz makes a difference in real listening situations. The early and slow rolloff has also advantages in theory (possibly lower delay, computationally cheaper).

I also don't think -1 dB at 17 kHz and -3 dB at 18.25 kHz makes a difference in real listening situations. The early and slow rolloff has also advantages in theory (possibly lower delay, computationally cheaper).

Such anti-aliasing filtering is necessary in a sample-rate and digital-to-analog conversion. As Sebastian indicates, there are trade offs in filter design. You are comparing Microsoft's software filter to the hardware filter in the DAC. They are implemented differently and it is not surprising that you can measure and hear a difference. Have you done any measurements on XP to confirm that there's a regression in Win 7. I would not assume that removal of user settings implies reduced performance. It could alternatively mean that overall performance was improved to the extent that user settings are no longer necessary.

I am well familiar with the technical details of resampling. There recently was an interesting discussion about reconstruction filters, where I participated, for example.

QUOTE (Notat @ Feb 10 2011, 16:43)

Have you done any measurements on XP to confirm that there's a regression in Win 7. I would not assume that removal of user settings implies reduced performance. It could alternatively mean that overall performance was improved to the extent that user settings are no longer necessary.

I remembered that Microsoft had claimed for the "best" setting to use a high-end polyphase filter in XP. It took me a while to dig up some reference. And after reading that what Microsoft used to call the "good" setting was simple linear interpolation, I think you have a point and they might just have removed the ultra-low-level options. From the measurements it is pretty clear that Windows 7 does not use linear interpolation anymore and they might have just kept the former "better" or "best" option.*

Still, anti-aliasing is not just a trade-off between pass-band quality and filter steepness. Both can be maximized at the cost of a third variable: CPU cycles. Compared to the vast power of even 5 year old commodity CPUs, Windows 7's frequency roll-off really is a little lame (it's not a phone OS). Music playback doesn't need a lot of resources on modern CPU's. Most of the time can be spent in the lower C states and the long pipelines must regularly flush without ever truly filling. In such a low usage scenario a little higher software utilization can often free-ride just by higher pipeline utilization. I certainly wouldn't mind having the option of not 99,9% but 100% transparency, without a limitation to what the majority would call normal music. Not because the difference would be so huge, but because of missing necessity. If a difference with whatever signal, even if can't be considered normal music, can be perceived, and CPU cycles are superabundant, then why be apologetic about it?

* I'm not planning to re-install XP just to get confirmation.

One more comment shared WASAPI: even shared WASAPI can switch the output sample rate to a rate different from the user-chosen, preferred output sample rate, when there are no conflicting streams. In such a scenario a shared WASAPI implementation can output audio without an application level resampler (you end up with no resampling at all). But such an implementation would be incomplete and throw an error, when you try to playback while a conflicting stream or system sound would occupy the engine with another sample rate. Even if the occupying source would also use shared mode.