 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
129.33.19.254
In Reply to: RE: Not bothering posted by Dawnrazor on October 5, 2011 at 21:48:36
Non-optimized PC it was installed into?
Follow Ups:
To be sure carc. the computer was not optimized....
But the thing that really made me skeptical was the foobar/ asio4all combo with a card that fully supports asio. Foobar is bad enough but to through in asio4all???
And the "comparison" with 2 separate computers. IMHO it just says that the impact of the computer, os, psu, etc. is not something this reviewer understands.
Why not do the comparison from the same computer???? Certainly it had usb connections....
> But the thing that really made me skeptical was the foobar/ asio4all combo
> with a card that fully supports asio. Foobar is bad enough but to through
> in asio4all???
If you read the review, you will see that I was trying to solve the problem
that with ASUS's own driver for the Xonar cards, 96k data were downsampled
even when the PC was apparently set-up correctly for bit-correct playback.
Actually, "downsampled" is not quite the correct word, as with the ASUS driver,
a 40kHz tone sampled at 96kHz played back with a frequency of 8kHz, ie,
was aliased from a sample rate of 48kHz. This didn't happen with ASIO4all,
IIRC, or the beta driver that ASUS eventually sent me after the review
had been published.
Hi John,
Sure but you state that playback was with Foobar and Asio4all. Asio4all mucks up the sound, and unless all your listening was done with 96k files (and even then) you werent getting the best sound from your system, and any comparison would be compromised.
That was just one of the issues.
For instance why was the Ayre run off a different computer?? How can you fairly compare the 2 if the computers are different? If you compare dacs dont you do it with the same transport???? Why would you switch in this case?? Certainly the shuttle had a spare usb port??
But it's a yes/no answer.
Did you guys use ASIO or not?
This is a dual-headed driver -> it functions under the WDM (Windows Driver Model) and ASIO. Personally, I avoid cards with C-media based chipsets and associated drivers like the plague. Recent codecs HAVE provided for non-resampled digital out and a greater variety of sample rates and this has found it's way to their cards. For example, the ASUS Xonar D2 that I tested had strange counter-intuitive ASIO channel mapping (at the time of testing) and also does NOT accomodate automatic sample rate detection.
But I digress - back to the issue at hand:
ASIO operation can be totally different from WDM operation, IME and withing WDM operation, waveout, kernel streaming, directsound and now the new WASAPI can all behave differently as well. This is especially true when it comes to things like volume controls and resampling. There are also certain things that people need to be aware of (that few understand completely) that need to be done in the Windows environment to ensure that bitperfect playback is obtained when using WDM. The lack of a clear and total understanding of how the various iterations of the windows audio stack actually behave (given complex condition sets) has led to a plethora of misinformation about when and how the stack resamples. Some said that the stack ALWAYS resamples to 48khz, and is on ALL THE TIME (even with one stream) and kernel streaming is the only way to get bitperfect playback. Wrong. I was able to get bitperfect out using directsound (out of windows media player actually!) through to a receiver using a DTS test track that will scramble not only with resampling but even due to a simple volume bit change! The DTS test (if it can be used) is truly definitive.
So back to the review in question. The fact ASIO4ALL "cured a problem" is not proof positive there was a problem at all. Huh? In other words: the fact that there was resmpling going on does not mean (necessarily) that the driver is inherently defective. It *could* just mean that on that particular PC with that particular OS/Service Pack/Settings and that particular player and those particular Windows Audio settings that the windows digital mixer was being envoked for SOME REASON. It could be as simple as a microphone input being "on" or a seemingly innocent application polling the WDM driver causing the resampling engine to be enabled. Resampling can be enabled without "hearing" something being mixed in as well, something that many people also miss. It can be a negligible noise floor - the point is that a second data stream is present - even if that data stream seems to contain "nothing", its' still "there", just like zeroes in a true digital (-inf db) silence still results in a data stream. It's streaming zeroes - but it's still streaming.
I don't doubt the reviewer had an issue with the card. It's just his explanation for the problem which is not, in my mind, adequately definitive. I've done EXHAUSTIVE tests of WDM drivers (Direct Sound, Waveout, Kernel streaming), ASIO4ALL and ASIO drivers using various audio interfaces and let me tell you - there are some seemingly innocent or innocuous variables and settings that can cause digital mixing to be invoked. Worse yet, 90% of "definitive intel" out there in cyberspace is a combination of data that is either incomplete, partially incorrect, correct only for a specific condition set(s), or just dead wrong.
I'd love to install this card and run it through one of my "bitperfect" test batteries and see if this condition can be emulated, then provide what would be a more concise explanation as to the source of the resampling in non-ASIO mode.
I'm not a fanboy of this card at all. I already stated that I returned to the store it's little brother (in other posts). My agenda here is really simple: we need to be careful not to create false corollary especially about resampling because this information spreads like wildfire in our surprisingly small little online world of computer audio.
I liked the review. But I think the resampling part requires further investigation (or at least further explanation). Maybe the test done was definitive. Or maybe it was not. Too little info to say one way or the other.
Cheers,
Presto
considered posting a short and easy to understand summary of how to?
This will be of great help to inmates.
Is search for previously posted methods (me and others) and see if I can refer to them. Plus I need to check it for accuracy up to and including XP. Then I would need some volunteers to repeat said tests under Vista/Win7 to confirm behavior of WASAPI.
The test works well for digital outs (SPDIF, AES/EBU, USB and likely firewire devices as well). Any change to the bit accuracy of the DTS encoded test track scrambles the info the decoder needs at the other end. There is the trick - you need to send you data into a device which can decode DTS streams. It's not a valid or practical test for ALL applications, but when it's usable, it's always definitive and makes bitperfect troubleshooting in real time a breeze. When you are bitperfect, you get music. When you're not you get thissssssssssss. And you can actually get digital mixing to engage/disengage DURING playback and begin to make real corollary between things that affect bitperfect playback and things that dont - for EACH type of output you want to use or test. I wish I made a proper test report... I believe it's time to repeat this whole experiment, and on different OS as well.
I still use XP because I have drivers for all the hardware I have here, it works without hiccup, the OS is stripped down for dedicated audio usage, and I think I get fantastic sound where the OS is not the weakest link (hardware is now where I think I can get the most benefit from upgrade).
I really need to find the originator(s) of this test and give him/them proper accreditation for this fantastic idea.
Cheers,
Presto
The two most important items one must have are:1. A means of ascertaining the actual speed the sound card is outputting.
2. A means of verifying (when this speed matches the sample rate of a file) that the output to the DAC matches bit for bit the content of the file.
There is little or no point in doing any further optimizations until one if confident that the music we purchased (possibly as modified deliberately by us) is actually reaching the DAC. Of course, once this has been achieved there is still the question of getting good sound because of more subtle and difficult problems, e.g. jitter and electrical noise. But if the wrong bits are getting out this is hardly important.
There are basically only two ways of getting the right bits out: trust or verify. Given the immense complexity and lack of transparency of all the software in a modern PC, (no matter what the type) and the track record of numerous vendors, IMO "trust" is an absurd concept. One is left, therefore with "verify".
In some (rare) circumstances, I've had resampling situations that actually resulted in a PITCH CHANGE. How noticeable is a pitch change from 44.1 to 48 or 48 to 44.1? On unfamiliar material, it might go by unnoticed! (This is what, like a "half" semi-tone in pitch change??)
So another test would be to play 44.1 and 88.2 of the same material to make double-sure there is no pitch change going on.
With DTS passthrough test, though, ANY resampling or ANY volume bit change (any change at all, then) will result in thissssssssssss.
It's a good test! And I've tested the test too... :P
You're right, but I would add:
-Trust OR
-Verify using a proven test method
Cheers,
Presto
Yeah, proven test method for sure. But I'm not sure how to explain this to people, because if one gets a magic "test box" that says "pass" or "fail" then one ends up having to trust this box. Or trust some inmate that his "proven" method actually works. :-)
Switching between 44.1 and 48.1 amounts to 8 percent, a little more than a half step (e.g. C to c#). Nearly all music lovers will hear this in an immediate comparison but only a minority (those with perfect pitch) are likely to notice this error in isolation. It's much less of a "ha-ha" than running a 45 vs. 33 1/3.
In the past I've managed to trick my system into making gross errors, e.g. 88.2 vs. 44.1. This goes beyond subtle or annoying and enters into the amusing category. (So far it has happened only when I was already trying to "trick" my system, otherwise it would definitely have been annoying.)
Yes. Half a note!
But from 44.1 to 88.2 or 96 anyone should be able to hear the chipmunks.
I work as a technologist in electrical engineering. We're always required to prove "black box" mathmatical models or algorithms with alternate calculations.
Too much "hey we got an answer, wonderful" in some areas.
And G.I.G.O. still applies too...
Cheers,
Presto
My dCS972 tells me all that. Even shows bit activity.
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2024, Audio Asylum, all rights reserved ]
