Support Head-Fi.org by
starting all of your
Amazon.com shopping by
clicking here.
____________________________________________________________________
Today's Featured Head-Fi Blog: Jude's Blog
____________________________________________________________________
Please help
support Head-Fi by becoming a Contributing Member
CLICK
HERE -- Contributing Members, thank you
for your generous support! --
. . . linux? Any testing on linux???? Anything????
Not yet. We don't have a linux machine set up, but I am considering doing that in the near future. I'll try to keep you all updated, but the new Benchmark Wiki should have an announcement when any new developments or tests happen.
While the ability to hear any differences between a bit perfect stream and a kmixer modified stream is one thing that is a bit different from the question of being bit perfect.
I do most (98%) of my listening through studio monitors (JBL 6332, Tannoy Reveal 6, and K&H 4-ways). I hope my lack of headphone experience doesn't disqualify me from this forum .
Not at all. Come to the NYC Meet tomorrow and we'll get you sorted out.
there is no question that kmixer modifies 16/44.1 PCM streams and there is nothing you can do about it short of bypassing kmixer.
1) Microsoft documentation clearly states that kmixer will pass a single audio stream through unaltered if the destination device supports the incoming sample rate.
2) Elias states that in Benchmark's testing, the stream recovered from the USB passthrough was bit-for-bit identical to the stream heading into the kmixer/usbaudio stack.
In light of these 2 facts, how do you subtantiate your claim that "there is no question that kmixer modifies" the stream?
Originally Posted by thomaspf
Your test might not be perfect in that you don't catch these modifications but you can take my word for it that they are different.
Again, Benchmark's test compares the outgoing digital stream with the recovered digital stream and Elias states these were bit-for-bit identical. Are you suggesting the test is "not perfect" in that they can't tell the difference between a 1 and a 0 at a given stream position? Since the entire test is in the digital domain, it doesn't leave room for golden-ear testing/opinion. Are we supposed to take your word over direct binary comparison?
I have also spend a long time doing testing. Something does not add up, so we just need to get to the bottom of it but there is nothing to get emotional about.
Maybe I am wrong or the by pure accident the pseudo random test stream happens to get passed through unharmed. I am not doubting that the DAC1 is a great product and I always like computer focused audio devices or I would not be here. We will just have to find out.
Well one thing's for sure, Kmixer cannot alter a stream and pass it through unchanged at the same time. If numerous tests show identical bit transfer then apparently Kmixer does not alter the signal unless something else is interfering, which is what Benchmark found and what MS is saying.
I tend to believe specific tests that prove a case. I don't know what tests you have performed to come to a different result but I'm interested to know as this might help us avoid compromised sound in the future, if it is indeed compromised.
Sometimes I wonder about anecdotal results because some claim that different media players sound better than others when using the same streams and same output devices which seems like total nonsense to me. Same with claims that KS and ASIO sound different when they are outputting identical streams through identical devices.
It would certainly be nice to put this all too often misunderstood subject to bed.
That is exactly what we are trying to do. I have performed a bunch of different tests all with the consistent results. For the USB specific tests I have been using an Audiotrak Optoplay which has been on the market for a couple of years and which happens to also use an TUS1020 chip that uses the standard USBaudio.sys driver up to 24/96. I don't believe there is any special firmware used on the converter.
1. Recording a stream send out via the Audiotrak Optoplay. The resulting stream is different when using Directsound (kmixer) and is identical when using kernel streaming.
2. Playback of PCM wav streams with an embedded DTS signal to a surround sound receiver. The receiver can not lock on to the surround encoding with Directsound but the same stream works just fine with kernel streaming.
3. Playback of the udial test clip. I get completely black background with kernel streaming but distortions with Directsound.
Oh boy. More snake oil. The line output is voltage dependent, not current dependent. The input to your amplifier is specified in terms of Volts. Like 2V RMS. SO why do they need a high current going in t perhaps a 47K input on your amp? To blow your amp input up?
I pass.
They're referring to the balanced XLR outputs, not the line outputs:
Originally Posted by Elias Gwinn, Engineer, Benchmark Systems (on AudioAsylum)
High-current output drivers. The balanced output drivers are designed to handle low impedance, high capacitance, and/or high-inductance loads without the THD+N suffering.
Guys, you don't need KernelStreaming or ASIO for bit-identical output. I had a Audigy NX usb sound card in the past and it plays 16bit 44.1k DTS CD fine using DirectSound and foobar. My receiver will show DTS when a DTS track comes on. If it is not bit-perfect the sound will be white noise.
Coincidentally, I never had much luck with KernelStreaming or ASIO myself. They simply do not work at all for me.
Are you using the Microsoft USB driver for the Audigy? The Transit also works bit perfect but it also comes with it's own driver.
Do you actually mean the Audigy 2NX? When I last tried that model it did not work bit perfect. If this is true that would be fantastic news, since that model is one of the very few that is using asynchronous mode for the USB audio. This means that the master clock of the playback is in the Audigy and the PC is slaved to it via a back channel that performs the rate control.
.
Linear Mode
