[Scrith]

Here is a link to a very interesting question-and-answer round with several computer-based audio experts on the state of current computer audio technology.

Some of the most interesting answers were from Charles Hansen of Ayre Acoustics. Ayre is going to be releasing a new USB DAC in March that uses the asynchronous approach to USB audio (as I told Elias about several months ago). Here are Mr. Hansen's thoughts on a question about USB and other computer interfaces to DACs:

Quote:

USB - There are a ton of USB DACs out there that suck. The problem is that Burr-Brown released a bunch of cheap chips that had both a DAC and USB support. (Some also have a digital out, as used in the Wadia dock.) They are super easy to use and require no programming. But they have two problems. The first is that they are limited to a max resolution of 48/16. The second is that the jitter performance is HORRIBLE. We are talking literally 100x worse than a good one-box CD player. There is another chip from Burr-Brown called the TAS1020B. It is programmable, but it is super hard to do so. Only two people have done it in audio to my knowledge. There is a third- party developer called Centrance that has written code for the device that allows it to go up to 96/24. This is used by some pro companies like Benchmark and Lavry. Some high end companies like PS Audio and Bel Canto also use it. But they have done nothing to address the HORRIBLE jitter performance. About the only good thing about this approach is that the DAC is not built in. Therefore, many of these guys use jitter reduction devices, typically a sample-rate converter (SRC), before the DAC chip. But the best way to do USB is what is called "asynchronous" mode. This means that the master audio clock is in the DAC box instead of the computer. This is the only way to get jitter performance as low as a good one-box player. Gordon Rankin of Wavelength wrote the code for the TAS1020B to do this, and we are licensing it from him. dCS also has some new add-on boxes for their big stacks of boxes that uses "asynchronous" mode. Everything else is seriously flawed by comparison. Using an SRC chip to reduce jitter is somewhat controversial from a sonic standpoint. (They tend to measure well enough.) Basically, what they do is throw away all of the original data and calculate new data that is their best guess as to what the data would have been if there hadn't been any jitter. The "best guess" refers to the algorithm used. The latest ones measure extremely well, but still haven't convinced everyone from a sonic standpoint.

Any thoughts on those comments, Elias?

 

[Quaddy]

good linkage, am gonna have a good read now. thanks.

 

[Lord Chaos]

Scene: Inside the Benchmark Media Systems boardroom

President: "Folks, we've been busted."
Engineer 1: "I told you we shouldn't have used that cheap chip."
Engineer 2: "But it sounds really good!"
President: "I'm afraid that's no longer good enough. We have to have the words to back it up now."
Engineer 1: "What do you want us to do?"
President: "I need you to scrap all of your DAC designs and start over. Oh... we'll need the new design by next Thursday."
Engineer 1: "Yes, Sir!"
Engineer 2, as they walk out the door: "But... they sound so good!"

 

[tubaman]

Let's not forget the DAC1 USB is only $300 more than the DAC1, which is $1,000.

 

[EliasGwinn]

Quote:

Originally Posted by tubaman /img/forum/go_quote.gif I'm getting a DAC1 PRE and I have a question regarding the analog input. With the analog input as the selected source and the output set at "calibrated," is it equal (volume) as turning the vol. all the way up (or so) using "variable?" I plan to connect the tuner to my DAC1 PRE and then output to the headphone amp.

Hello Tubaman,

At factory setting, the 'Calibrated' output will about 3 dB below the maximum variable setting (assuming the input level isn't too high to limit the output).

Thanks,
Elias

 

[EliasGwinn]

Quote:

Originally Posted by Scrith /img/forum/go_quote.gif Here is a link to a very interesting question-and-answer round with several computer-based audio experts on the state of current computer audio technology. Some of the most interesting answers were from Charles Hansen of Ayre Acoustics. Ayre is going to be releasing a new USB DAC in March that uses the asynchronous approach to USB audio (as I told Elias about several months ago). Here are Mr. Hansen's thoughts on a question about USB and other computer interfaces to DACs: Any thoughts on those comments, Elias?

Mr. Hansen may be an eloquent speaker ("There are a ton of USB DACs out there that suck"), but I must disagree with him on a few points:

1. Centrance didn't "program" the TAS1020B. Centrance sells a firmware solution that was co-developed between them and Benchmark.

2. Lavry doesn't have a USB product, as far as I know. Could be wrong...

3. As I mentioned in previous posts (somewhere around #2100), asynchronous USB does not reduce jitter to levels low enough to eliminate the need for a jitter mechanism in the DAC.

4. As I also mentioned in previous posts (somewhere around #2100), asynchronous necessitates SRC by the computer, which is WAY worse then the ASRC in our box.

5. "Everything else is seriously flawed." Coming from a DAC manufacturer, I question the objectivity of this statement.

6. "Basically, what they do is throw away all of the original data and calculate new data that is their best guess as to what the data would have been if there hadn't been any jitter. The "best guess" refers to the algorithm used. The latest ones measure extremely well, but still haven't convinced everyone from a sonic standpoint." With the exception of the statement "measure extremely well", nothing in this quote is true. "still haven't convinced everyone from a sonic standpoint."...does this mean that no one thinks the DAC1 sounds good???

Thanks,
Elias

 

[Scrith]

Thanks for the reply Elias.

You're definitely right about there being some bias (and misinformation) in Mr. Hansen's replies (the DAC1 sounds and measures remarkably well, by almost all accounts, including mine!). But it could probably be even better, couldn't it?

On point 3: data that is sent asynchronously does not contain jitter because there is no timing associated with it (it is just data that has been sent to an external device to use at the rate at which it sees fit). One example of something like this is a printer, which is sent data (to be printed) at a rate at which the printer determines (the computer cannot possibly know how quickly the printer can consume the data, so it must wait for a signal from the printer before sending additional data). USB audio can work this way also (I'm not sure whose bright idea it was to have the computer determine the rate at which the data is being sent...probably the same people who figured out S/PDIF), and that is what people mean when they talk about asynchronous USB. If the device in question is buffering this data and asking (and receiving) it such that buffer over- and under-runs do not occur (not a difficult task...this is what USB printers and hard drives are doing) the device can play back this data at a rate that is entirely independent of the rate at which the data arrived (much like a printer can print at its own pace).

On point 4: why would I need to use SRC on my computer if I am sending data to an external device? If the external DAC is like an audio printer (as described above) it will take the data at whatever rate it arrives and play it back at the expected rate based on its local clock. The data does not need to be resampled to something other than 16/44 in order for the DAC to play it (or am I missing something about DAC chips not being able to use data in standard formats like 16/44 and 24/96?).

 

[EliasGwinn]

Quote:

Originally Posted by Lord Chaos /img/forum/go_quote.gif Scene: Inside the Benchmark Media Systems boardroom President: "Folks, we've been busted." Engineer 1: "I told you we shouldn't have used that cheap chip." Engineer 2: "But it sounds really good!" President: "I'm afraid that's no longer good enough. We have to have the words to back it up now." Engineer 1: "What do you want us to do?" President: "I need you to scrap all of your DAC designs and start over. Oh... we'll need the new design by next Thursday." Engineer 1: "Yes, Sir!" Engineer 2, as they walk out the door: "But... they sound so good!"

It's actually the same chip, just different implementations. Also, the president is also Engineer #1...John Siao.

Thanks,
Elias

 

[EliasGwinn]

Quote:

Originally Posted by tubaman /img/forum/go_quote.gif Let's not forget the DAC1 USB is only $300 more than the DAC1, which is $1,000.

Its not a question of cost, its just a different implementation of the same USB chip. We looked at the Asynchronous mode in Fall '07, but when we learned that it would induce SRC by the computer, we quickly realized it was a really bad idea.

Thanks,
Elias

 

[EliasGwinn]

Quote:

Originally Posted by Scrith /img/forum/go_quote.gif You're definitely right about there being some bias (and misinformation) in Mr. Hansen's replies (the DAC1 sounds and measures remarkably well, by almost all accounts, including mine!). But it could probably be even better, couldn't it?

Perhaps, but I don't think this would help at all. Even if this method as perfect as they claim it is, it wouldn't affect the performance of the DAC1 because jitter is a non-issue.

You might say, "You could eliminate the ASRC if there was no jitter!" Sure, but then the digital filters wouldn't perform as well. There are major sonic benefits to converting the sample-rate to 110 kHz, and Mr. Hansen isn't considering this at all. He thinks the ASRC is strictly a method to deal with jitter. It does that and much more.

Quote:

Originally Posted by Scrith /img/forum/go_quote.gif On point 3: data that is sent asynchronously does not contain jitter because there is no timing associated with it (it is just data that has been sent to an external device to use at the rate at which it sees fit). One example of something like this is a printer, which is sent data (to be printed) at a rate at which the printer determines (the computer cannot possibly know how quickly the printer can consume the data, so it must wait for a signal from the printer before sending additional data). (I'm not sure whose bright idea it was to have the computer determine the rate at which the data is being sent...probably the same people who figured out S/PDIF), and that is what people mean when they talk about asynchronous USB.

The isn't exactly how asynchronous USB Audio works. What your describing is bulk transfer, where data is sent in packets when needed. USB audio is isochronous transfer. Isochronous means that the data transfer is happening at a regular (periodic) rate. 'Asynchronous', in the case of isochronous USB audio transfer mode, refers to 'not synchronized to the computer.' Instead, it is synchronized to an external clock...the DAC in this case.

Quote:

Originally Posted by Scrith /img/forum/go_quote.gif If the device in question is buffering this data and asking (and receiving) it such that buffer over- and under-runs do not occur (not a difficult task...this is what USB printers and hard drives are doing) the device can play back this data at a rate that is entirely independent of the rate at which the data arrived (much like a printer can print at its own pace).

Not really...remember, USB audio is 'isochronous', not 'bulk' transfer mode.

Quote:

Originally Posted by Scrith /img/forum/go_quote.gif On point 4: why would I need to use SRC on my computer if I am sending data to an external device? If the external DAC is like an audio printer (as described above) it will take the data at whatever rate it arrives and play it back at the expected rate based on its local clock. The data does not need to be resampled to something other than 16/44 in order for the DAC to play it (or am I missing something about DAC chips not being able to use data in standard formats like 16/44 and 24/96?).

It's not that YOU need to use SRC on your computer... Its that the computer will have to re-sample the data to correspond to the new clock...the master clock....the clock from the USB audio device. I posted about this previously (somewhere around +/- post# 2100).

Example: What if Mr. Hansen's USB audio device says, "Send me all audio data at my sample-rate: 44.1001 kHz (or 48k, or 96k)." USBaudio.sys looks at the audio stack, which is sending audio at 44.1002 from iTunes. How does it reconcile that difference? It must re-sample.

When we designed the Benchmark/Centrance solution, we said, "Why don't we allow the computer to be master so the sample-rate can stay consistent until it enters the DAC1? Jitter isn't an issue...only bit-transparency. Just send us the proper data, and we'll take care of the rest!!"

Whereas the asynchronous mode causes SRC...offers a non-transparent data path...and doesn't do anything for jitter... We are quite happy of our solution!

Thanks,
Elias

 

[Scrith]

Sorry for the distraction Elias and everyone, but I think this is an interesting technical path to venture down. And so I continue:

Well I admit that I simplified it a bit in my description of how the asynchronous mode for USB audio works (I didn't mean to imply it was using a bulk transfer mode, like hard drives and printers, but merely to describe the asynchronous mode that it is using in those terms, which I think is viable because it is controlling the outgoing data rate, like those devices are doing). In the Asynchronous mode of USB audio, the endpoint (e.g. DAC) cannot tell the source (e.g. computer) to stop and start, but it can tell the computer to slow down (when the DAC's buffer, which is being consumed based entirely upon a clock local to the DAC, is getting full) or speed up (when its buffer is getting low). The computer does not decide to send data at a certain rate (as your iTunes at 44.10002 example states), it sends data at a rate controlled by the DAC. What you are describing is the "adaptive" mode of USB audio (the DAC regularly adjusts its clock/PLL, which is used to resample the incoming data to the desired rate, based on the average incoming data rate).

This is a very important distinction...the DAC is controlling the rate the data is being sent by the computer. This eliminates the need for any resampling (the data will be consumed by the DAC from its buffer at precisely the rate its local clock requires...so it does NOT need to resample from 44.10002 to 44.10000...it can simply use the data at 44.1000 and tell the computer to slow down if it is trying to send the data at 44.10002).

Now, the part about the DAC chip *wanting* the data at 110K...that I do not know anything about. If there is some inherent advantage to that (and perhaps you have measured the performance of the chip the DAC1 is using and determined that it does indeed do a better job with data resampled to 110K than with data at 44.1K that has not been resampled) then we may be getting to the crux of the matter (why the DAC1 is resampling). But, even so, wouldn't it be better to resample data from a known rate (exactly 44.10000) than a variable rate (whatever the recent average incoming data rate is...say the iTunes 44.10002 that you used as an example)?

Here is a link to a post by John Swenson (from a question I asked at Computer Audio Asylum about this very topic in 2005) that explains the differences between the isochronous USB audio modes a bit better than I can.

 

[tubaman]

From my prior experience with the DAC1 USB I know the unit can run pretty hot, but how hot is too hot? Is overheating ever a concern?

I put a HRS Damping Plate, which is 5.5 x 4.5 x 0.7 (inch) and basically made of plastic, on top of my DAC1 PRE. Plastic surface supposedly traps heat, should I be concerned about this?

HRS Damping Plate:
Damping Plate reduces vibrations on audio or video performance

 

[bigfishybob]

Hi guys

I'm interested in buying a Benchmark DAC1 USB. Does anyone know if this is Vista 64 compatible?

Apologies if this has been covered already.

Thanks

 

[HeadLover]

I am using it with Vista 64bit
Works great!

 

[bigfishybob]

Quote:

Originally Posted by HeadLover /img/forum/go_quote.gif I am using it with Vista 64bit Works great!

Great. Thanks for the quick reply.