Feb 28, 2007 at 10:59 PM Post #76 of 3,058
Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif
As for a specific product, I don't feel comfortable recommending one because I'm not sure what our company policy is with that regard. It's a fair question, but its one I don't know how to answer fairly. Please forgive me.


What I understood from your postings are, we should choose the interfaces that uses native usb drivers.

Is it correct?
 
Mar 1, 2007 at 2:36 AM Post #77 of 3,058
Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif
This is theoretically true, but USB wasn't really built for steady streaming, even in Isochronous. When you watch the stream on a bus analyzer, it becomes apparent.

I think what happens is...USB activity is sort of a queued process, and follows the queue with relative prorioty, etc. Therefore, when other activity takes priority, USB activity is compromised.

I wish I knew with certainty, but even the most official publications on this will disagree with each other!!

Nonetheless, USB audio does suffer from 'ticks' and drop outs, which, for whatever reason, is due to insufficient streaming capabilities. When developing the DAC1 USB, we put several "checks" and buffers into place to monitor the stream and prevent these errors from occuring. We played audio through the DAC1 USB while taxing the processor of the computer with other apps, etc, and we couldn't get the DAC1 USB to tick or pop.




Does this mean that you are using asynchronous USB protocol for Win2000, XP and Vista?

Steve N.
 
Mar 1, 2007 at 3:22 AM Post #78 of 3,058
Hi Elias,

It's always great to have a company stand behinds it products but some of what you posted here differs a bit from my experiences. So let me question some of the statements you made in order to avoid any confusions on this forum.

1. If your sound card driver uses kmixer than the bits will get altered even if only a single stream is playing. What procedure did you use to test this otherwise? You'd be the first to come to a different conclusion.

2. The Windows standard USB driver uses kmixer and any USB audio device using the standard driver will not work bit perfect unless you use kernel streaming. Vista which does not have kmixer anymore uses a different mixer but is still not bit perfect. Is Benchmark shipping with a different USB driver?

3. I was also intrigued by your statement of a clock recovery system in the DAC1. Is that a new feature in the USB model. As far as I understood up to now, the DAC1 does not use any form of clock recovery at all but is using an AD1896 asynchronous sample rate converter running at a fixed frequency. While that reduces jitter is also changes all the samples in the process and therefore the DAC1 never actually plays bit perfect. Is that not correct?

Cheers

Thomas
 
Mar 1, 2007 at 3:22 AM Post #79 of 3,058
Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif
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
frown.gif
.

The headphones we have here at Benchmark are the Sennheiser 650 and 600's, as well as a few different Ultrasone's. At the recording studio where I work, we have the AKG K 240's and Sony MDR7509HD's.



icon10.gif
icon10.gif
Since you guys primarily use Senns, you obviously have a good ear and taste
600smile.gif
icon10.gif
Must be why I like the DAC-1 with my Senns.
600smile.gif
Grados aren't so bad either
icon10.gif
As a Benchmark owner, this is proving a gread thread to read. You're certainly more then welcome here to provide insight on the specifications of Benchmark products. Welcome to the forum, Elias!

Dave
 
Mar 1, 2007 at 9:43 AM Post #80 of 3,058
Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif
With all that being said, a high quality transport will offer better error correction for disc errors. If the DAC1 is used, the only reason to spend money on a high quality transport is for better error correction. The USB solution, however, should be every bit (excuse the pun) as stable as a good transport, provided the harddrive isn't too fragmented, etc, etc.



an option is to play your music from the RAM rather than from the HDD. Foobar can do it: buffering option

and of course rip your file with EAC in secure mode to a lossless format.

if you do it this way I doubt a CD transport would be better.
 
Mar 1, 2007 at 9:51 AM Post #81 of 3,058
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
Hi Elias,

It's always great to have a company stand behinds it products but some of what you posted here differs a bit from my experiences. So let me question some of the statements you made in order to avoid any confusions on this forum.

1. If your sound card driver uses kmixer than the bits will get altered even if only a single stream is playing. What procedure did you use to test this otherwise? You'd be the first to come to a different conclusion.

2. The Windows standard USB driver uses kmixer and any USB audio device using the standard driver will not work bit perfect unless you use kernel streaming. Vista which does not have kmixer anymore uses a different mixer but is still not bit perfect. Is Benchmark shipping with a different USB driver?


Thomas



I'm pretty sure he said that they used an AP to test their dac.(http://ap.com)
 
Mar 1, 2007 at 10:35 AM Post #82 of 3,058
Quote:

Originally Posted by greenleaf /img/forum/go_quote.gif
an option is to play your music from the RAM rather than from the HDD. Foobar can do it: buffering option


Didn't know you could do that; I'm going to set mine to 100MB and go from there. Thanks a lot!

How is that different from a long output buffer length eg 8 seconds.
 
Mar 1, 2007 at 10:52 AM Post #83 of 3,058
Quote:

Originally Posted by milkpowder /img/forum/go_quote.gif
Didn't know you could do that; I'm going to set mine to 100MB and go from there. Thanks a lot!

How is that different from a long output buffer length eg 8 seconds.



well, with this option you basically buffer the whole song
biggrin.gif
.
and foobar will only buffer one song at a time (well, I think) so using a very high value is useless; unless you rip your music to image [one file per cd] + cue sheet; then I think it will basically buffer the whole cd but you'll need like 300mb RAM if you rip to lossless
biggrin.gif
. I don't rip to image+cue, I rip to single flac files so I haven't tested this...
 
Mar 1, 2007 at 11:08 AM Post #84 of 3,058
kk... I just set my buffer to the largest music file I'd potentially be playing, which is 135MB. How does the buffer work if I use upsampling (which I don't, but theoretically speaking)? Would the file be upsampled before being buffered or upsampled as the data is being read from the ram?

BTW, I yearn for a Benchy DAC1... I have no money though and the UK dealer's prices are extortionate.
 
Mar 1, 2007 at 2:31 PM Post #85 of 3,058
Quote:

Originally Posted by 5Kurt /img/forum/go_quote.gif
What I understood from your postings are, we should choose the interfaces that uses native usb drivers.

Is it correct?



5Kurt,

From our experiences, native drivers are bit transparent for 16-bit only (DAC1 USB not included...it is transparent at 24-bit). This is dangerous even when playing 16-bit files because volume adjustments in software, etc result in 24-bit words due to division. On the contrary, we rarely achieved bit-transparency with devices using custom drivers. But they were capable of 24-bit. The custom-driver devices, though not transparent, did not result in significant distortion. But, at the same time, all the bits are not making it through ok.

The ideal solution would be a 24-bit native solution...hence our design goal.
 
Mar 1, 2007 at 3:25 PM Post #87 of 3,058
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
Hi Elias,

It's always great to have a company stand behinds it products but some of what you posted here differs a bit from my experiences. So let me question some of the statements you made in order to avoid any confusions on this forum.

1. If your sound card driver uses kmixer than the bits will get altered even if only a single stream is playing. What procedure did you use to test this otherwise? You'd be the first to come to a different conclusion.

2. The Windows standard USB driver uses kmixer and any USB audio device using the standard driver will not work bit perfect unless you use kernel streaming. Vista which does not have kmixer anymore uses a different mixer but is still not bit perfect. Is Benchmark shipping with a different USB driver?

3. I was also intrigued by your statement of a clock recovery system in the DAC1. Is that a new feature in the USB model. As far as I understood up to now, the DAC1 does not use any form of clock recovery at all but is using an AD1896 asynchronous sample rate converter running at a fixed frequency. While that reduces jitter is also changes all the samples in the process and therefore the DAC1 never actually plays bit perfect. Is that not correct?

Cheers

Thomas



Thomas,

I answered your first two questions in some detail in a previous post:

http://www.head-fi.org/forums/showpo...4&postcount=39

But here's the testing method:

"The testing consisted of the 'psuedo-random' bit-test that was mentioned in the press release. This is, quiet simply, testing "what-bits-go-in-and-what-bits-come-out". This is a standard test developed by Audio Precision, the leading audio electronics testing equipment manufacturer. When the Audio Precision (AP) sends a digital audio signal into a device, it checks to see if the exact same bits come out. So, for example, if the AP sends in 101100111000, a 'bit-transparent' data path will output the exact same bits: 101100111000. This was our testing proceedure."

As for the question about the DAC1 clocking, it is true that we convert the sample-rate to a rate which the D-to-A chip is most efficient. Your assumption that the D-to-A is not getting a bit-perfect data stream is correct, but this is by design. A converter chip is going to perform best at a specific frequency, due simply to the real-life limitations of semiconductors. So from a distortion performance stand-point, it is best to convert to analog at the chips "favorite" sample-rate.

So, this raises the question of, "Why is it important to get bit-transparent audio from the computer if its not bit-transparent when it gets to the D-to-A chip?"

The answer, of course, is - who knows whats happening to audio when going through a computer system, etc. Its so hard to tell whats happening, and why, and what affect its having on the audio. All we know is, we want the audio to come out untouched, and there is no reason why it shouldn't be the case. Also, you can be sure that any signal processing happening behind the scenes in the computer is not done with the D-to-A's best interest in mind as it is with the DAC1.

Unlike in a computer, we know what is happening to the audio within the DAC1, every step of the way. And, everything that is happening is done with absolute care and specific design with the goal in mind to achieve the most accurate (least distortion) conversion possible. If the ideal D-to-A chip existed that performed equally well at all sample-rates, we would be using it, and so would every other D-to-A manufacturer. Unfortunately, real-life limitations must be taken into account. Well, perhaps I should say fortunately, because thats what makes an engineer's job special, and exciting, and challenging. And, I should say, secure
tongue.gif
.
 
Mar 1, 2007 at 3:51 PM Post #88 of 3,058
So does this mean that Kmixer only alters the bits in non-USB soundcards (that are not using custom drivers), whereas in straight USB output from a PC, Kmixer doesn not alter the bits?

Haven't we known all along that Kmixer didn't affect USB output?
 
Mar 1, 2007 at 5:02 PM Post #90 of 3,058
Quote:

Originally Posted by EliasGwinn
"The testing consisted of the 'psuedo-random' bit-test that was mentioned in the press release. This is, quiet simply, testing "what-bits-go-in-and-what-bits-come-out". This is a standard test developed by Audio Precision, the leading audio electronics testing equipment manufacturer. When the Audio Precision (AP) sends a digital audio signal into a device, it checks to see if the exact same bits come out. So, for example, if the AP sends in 101100111000, a 'bit-transparent' data path will output the exact same bits: 101100111000. This was our testing proceedure."


Hi Elias,


thanks for the follow-up. I am a bit familiar with the AP but ours does not have a USB sound card attached to it and even if it would I am unclear how you wold check for bit transparency with the DAC1. Let's assume you feed it a stream of whatever bits, how do you feed those bits back to the AP for comparison.

I have done this test by sending bits from one sound card to another and comparing the results for a couple of USB sound cards. My finding is that the bit stream is changed at the sender unless you use kernel streaming. Another quick test that is being used quite often is to send HDCD encoded data or DTS encoded PCM streams to a digital interface and check for the results via a HDCD capabale DAC or surround sound decoder. I think everyone agrees there is no good reason why the data is changed in the computer when only one stream is playing, it unfortunately is changed in most cases.

Since the DAC1 does not have a digital passthrough, does not provide HDCD decoding, and is stereo only your claims on bit transparency are a bit hard to challenge but allow me to assume you might be in error unless you provide some new insights. Maybe if you or someone with a USB version of the DAC1 would disclose the USB chip being used we can close this issue.

I believe on the clock recovery we basically say the same thing. The DAC1 does not have any clock recovery but relies on a standard off the shelf asynchronous sample rate conversion chip like many other designs as well.

Cheers

Thomas
 

Users who are viewing this thread

Back
Top