Benchmark DAC1 now available with USB

[Wavelength]

Elias,

Why use a fixed clock for the ARCS? Most people who have tested ARSC's feel they sound better when used on a fixed multiple like 2, 4... instead of fractional.

So say for 44.1 upsample to 88.2 or 176.4 and so forth.

In several of the recording studios I work with here (Sound Images, Ashley Shephard's Audio Grotto) feel that when recording that the use of multiples are the key to better results when down sampling. Most of the recordings we have done recently are done at 24/88.2 or 24/176.4 so the output to 16/44.1 sounds better.

On the dCS gear many have talked about there ability to change the upsampling on the fly and many feel that multiple over fractionals always sound better.

Your thoughts?
Thanks
Gordon

[thomaspf]

Originally Posted by luciyuspax

Yeah,your explanation was very clear. Thank you very much for the answer. Infinitesymphony, It is nice to know that my e-mu 0404 usb has bitperfect output.

I remember reading another post of EliasGwinn,in which he was explaining why they chose to go with default windows usb drivers for Benchmark DAC1. He had said that they had noticed that many of external usb sound cards using special usb drivers were not actually bit-perfect( he hadn't specified any brand of usb audio about this) and in most cases that windows' own usb audio drivers were bit perfect.

I think you got this the wrong way round. The Windows USB driver is known not to be bit perfect when used with DirectSound since it will always render kmixer. You can of course get around this by sending the audio data via Direct Kernel Streaming.

Custom drivers might be able to get around this and you can use any arbitrary DirectSound application.

The default Windows drivers have gotten a lot of testing over the years and are very stable.

Cheers

Thomas

[03lab]

Hi everyone, first post from a long time lurker and audiophile.

I'm looking to buy a DAC1 PRE but unfortunately the distributor in Germany and/or Benchmark must have forgotten to do the conversion from USD to EUR. The PRE goes for EUR 1600 around here, which means a hefty $1000 premium on what it sells for in the US, surely something must be wrong here. For $1000 I could easily fly to the US and pick one up myself!

Please advise as to where I can get one at reasonable cost. Thanks!

[spyderx]

Quick question:
I'm using a DAC1 USB. MacMini USB --> DAC1 Balanced --> BAT VK-300xSE --> Totem Hawk speakers

I'm using the balanced outs from the DAC1, into the BAT. I have it set for "calibrated" outs and I have not touched the -20db jumper inside the DAC1 or the calibration pots yet.

I seem to have pretty good range on the volume, with normal listening position around 90 (scale goes to 140 on the BAT).

Am I going to benefit SQ by dropping the to 0db attenuation on the DAC1? The BAT has an amazingly low noise floor, so I have no noise at all at these levels.

Thanks

[G-U-E-S-T]

Hi Elias,

I have a question about the ASRC function and the "jitter-immune" claims of the DAC1 products please.

As you said, the ASRC function of the DAC1 utilizes its own internal clock (instead of the recovered S/PDIF clock) when internally feeding samples to the DA chip. But before this happens, surely the recovered clock is being utilized by the ASRC algorithm, yes? [Otherwise the ordering of the samples as sent, would be unknown, when trying to reconstruct and zip them into the new sampling rate.]

And if so, would not any "primary" (pre-ASRC) jitter artifacts from the S/PDIF transfer, just be getting remapped to a higher sample rate - and then presented with less "secondary" (post-ASRC) jitter artifacts to the DAC chip?

Meaning, the pre-ASRC jitter artifacts from the transport-to-DAC1 transfer would still remain - even if the internal ASRC-chip next presented no jitter or artifacts of its own to the DAC-chip.

For an analogy: Like if a song is recorded with jittery digital equipment in the recording studio, and thus that original jitter gets onto the burned CD and is permanent - this jitter can never be later removed, no matter how jitter-free any later CD playback machine may be. (In this analogy, the ASRC-process represents the later CD playback machine.)

Is this what Benchmark means by marketing the DAC1 as "jitter-immune", with "no jitter artifacts presented to the DAC chip"? I'm just trying to better understand the details...

[Crowbar]

Originally Posted by G-U-E-S-T

But before this happens, surely the recovered clock is being utilized by the ASRC algorithm, yes? [Otherwise the ordering of the samples as sent, would be unknown, when trying to reconstruct and zip them into the new sampling rate.

And if so, would not any "primary" (pre-ASRC) jitter artifacts from the S/PDIF transfer, just be getting remapped to a higher sample rate - and then presented with less "secondary" (post-ASRC) jitter artifacts to the DAC chip?

Though this is not directly how it's implemented, in mathematical terms the rate estimation of the incoming clock is in effect low-pass filtered. Depending on where the corner of the filter is, you get a good amount of jitter attenuation above that frequency. The attenuation can be made very large. For example, the new ESS Sabre DAC chip has 0.1 Hz corner on its integrated ASRC's rate estimation, which is way below audio band. In theory about any modern ASRC including the one in the DAC1 should have any artifacts below audible levels, but I can pick out an audible difference difference between stand-alone CS and AD ASRC chips, the test board ESS sent me, and non-ASRC with the transport slaved to the DAC clock (all with AD797 I/V and buffer) (true, the DAC chips were different too, but those also are specced with artifacts below what should be audible level; in my experience ASRC/digital filter makes more difference and sigma delta DACs with the same external filter sound pretty much the same to me).

[infinitesymphony]

Originally Posted by G-U-E-S-T

For an analogy: Like if a song is recorded with jittery digital equipment in the recording studio, and thus that original jitter gets onto the burned CD and is permanent - this jitter can never be later removed, no matter how jitter-free any later CD playback machine may be. (In this analogy, the ASRC-process represents the later CD playback machine.)

But that's not true. For example, a pressed CD with a high jitter rate can be re-burned to have a lower jitter rate.

The timing of the incoming signal doesn't matter as long as all of the samples are sent correctly; this is the one part where the quality of the transport matters. If the stream is 44,100 Hz, that should be how many samples the reclocking system takes before sending out one second's worth of digital audio. The only point of reclocking is to reduce jitter--the resampling portion is separate. Or at least, that's my understanding of it.

[Crowbar]

[edit:nvm]

[thomaspf]

Originally Posted by infinitesymphony

But that's not true. For example, a pressed CD with a high jitter rate can be re-burned to have a lower jitter rate.

The timing of the incoming signal doesn't matter as long as all of the samples are sent correctly; this is the one part where the quality of the transport matters. If the stream is 44,100 Hz, that should be how many samples the reclocking system takes before sending out one second's worth of digital audio. The only point of reclocking is to reduce jitter--the resampling portion is separate. Or at least, that's my understanding of it.

You have to be careful with this. The original poster spoke about jitter in the recording chain. That is very different from "pit" jitter on a CD.

The jitter that is permanently added to the signal is created by the analog to digital converter and comes from the fact that the samples are not actually takes at equi distant intervalls but at times in the jitter intervall. This jitter can not be removed.

Pit jitter on CDs is a non issue with todays equipment. 20 years ago CD players operated synchronosly and created their output clock from the bit stream they read from the spinning disc. When CD players got added to cars a long time ago this technology did not work and the problem was solved correctly. The ouput clock is generated from a crystal and the rotational speed of the dics is adjusted asynchronously. As long as you can read the bits correctly reburning a disc is not going to make any difference.

PC drives which can for example be found in the highest end Meridian CD player read CD asynchronously in any case and even do rereads if they encounter any read errors.

Cheers

Thomas

[EliasGwinn]

Originally Posted by luciyuspax

Yeah,your explanation was very clear. Thank you very much for the answer. Infinitesymphony, It is nice to know that my e-mu 0404 usb has bitperfect output.

I remember reading another post of EliasGwinn,in which he was explaining why they chose to go with default windows usb drivers for Benchmark DAC1. He had said that they had noticed that many of external usb sound cards using special usb drivers were not actually bit-perfect( he hadn't specified any brand of usb audio about this) and in most cases that windows' own usb audio drivers were bit perfect.

Luciyuspax,

The bit-perfect issue is currently unresolved. The main issue is that our test equipment tells us one thing and an engineer at Microsoft has told us something else.

We use Audio Precision (AP) hardware and software, which is the leading digital and analog audio testing platform. However, our AP interface does not have USB input, so it can only test Kmixer's bit-transparency by proxy via a USB audio device.

We have tested several external USB audio interfaces, and the results we found is that the non-native devices all failed AP's bit-transparency test. The native devices that used Windows USB drivers and kmixer, etc, passed the bit-transparent test.

The engineer from Microsoft says that Kmixer uses floating point which will never have absolute bit-perfect transmission. We are speaking with them as well as AP to determine where the differences lie.

Thanks,
Elias