A) WASAPI doesn't force any player to resample. One has to resample only if it uses exclusive mode, and if it uses exclusive mode it's for a reason, not for the operating system to do the work for you.
B) The frequency that is set in the device configuration is precisely the samplerate at which it operates the final mix (if not in exclusive mode), and as such, the sampling rate at which other sources get resampled.
C) I have no idea what you've supposedly done, but let me be doubtful that simply upsampling causes the effect you show
(which isn't as big as you try to suggest. It's 7dB! )
D) Please, consider using adequate words in this forum. "This sucks" or "This 0wns" are not adequate words.
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.
WASAPI in shared mode sends the output to the audio engine. The audio engine will match the source with the capabilities of the driver and will resample to the settings in the audio panel.
In exclusive mode, the client can choose to open the stream in any audio format that the endpoint device supports. In shared mode, the client must open the stream in the mix format that is currently in use by the audio engine (or a format that is similar to the mix format). The audio engine's input streams and the output mix from the engine are all in this format.
Were you able to ABX that? 1dB of rolloff at 17kHz seems like it would be difficult enough with test tones, let alone real music.
QuoteIn exclusive mode, the client can choose to open the stream in any audio format that the endpoint device supports. In shared mode, the client must open the stream in the mix format that is currently in use by the audio engine (or a format that is similar to the mix format). The audio engine's input streams and the output mix from the engine are all in this format.
The difference is at most 2dB, where it matters,
Are you telling me that when I have set 24bits 96Khz in Sounds, and use Wasapi output in foobar2000 to play a 44Khz file, the wasapi driver in foobar is doing its own resampling to 96Khz without me knowing it?The post you gave is from 2005, and as it can be read in it, not even beta 2 of Windows Vista was released. Also, it is not explicit if he was talking about Wasapi in general, or specifically about exclusive mode. (Or even if exclusive mode was the only mode that was to be made available at that time)
Oh, and btw, i know what WASAPI exclusive mode is. I'm developing an output driver for my application which uses that.
I still don't understand how did you do that.Win 192 -> analog(?) -> OSX 96Khz -> something -> RMAA 44KhzWin 44 -> analog(?) -> OSX 96Khz -> something -> RMAA 44Khz
Figuratively speaking, WASAPI is nothing more but a revamped XP Audio Kernel with a few added traits ASIO had established.
Quote from: saratoga on 09 February, 2011, 03:56:53 PMWere you able to ABX that? 1dB of rolloff at 17kHz seems like it would be difficult enough with test tones, let alone real music.I waited for exactly that sentence upon first reading the original post. I mean, we ABX a lot - mp3 for example. Numerous tests around here have shown that people cannot percept missing frequencies above roughly 15 kHz. I´m afraid this thread will get sorted into the "mp3-bashing-audiophile-snake-oil" sort.
How do you base such claims. The audio system has undergone a huge rewrite. ASIO isn't faster than WaveRT and there is a nice, modular architecture for any additionally needed features.
While it's preferable that audibility should be verified, in contrast to MP3 technologies such as resampling should not (for lack of a better phrase) mess around with the audio (the frequencies they preserve), so isn't there some merit to reporting deficiencies like these, regardless of audibility? Then it wouldn't be a case of saying "This sounds worse/awful", just "This has been subjected to sub-par processing".
Did you take the effects of different recontruction low pass filters into account?
[...] the 192 kHz -> 192 kHz loop-back test was nice and flat (better than -0.5 dB at 50 kHz).
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).
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 think you should really try 44.1 -> 96kHz and check if that is OK.