Squeeze Box Love'n'hate

Steve N.
Can you please explain how the use of the pacecar reclocker would be of benefit when used between the SQBX3 and DAC1, over a good true 75 ohm tranmission line in s/pdif mode? As I understand it, the Benchmark DAC1 has an AKM 4114 S/Pdif receiver which extracts the data, and clock. This clock and data are then connected to the Analog Devices AD1896 sample rate converter. The AD1896 besides its upsample and down sample function has two clock inputs: 1 from the serial data (from the AKM), and 1 master ref clk input. The AD1896 is a fully asynchronous design, and as such the serial clock drives the data into a FIFO, while the other clock (master, a crystal in this case) controls the FIFO output port. It is this asynchronous SRC that is responsible for the isolation from the jitter-ed data. The next down stream chip is the actual DAC, an analog devices 1853. This guy also has its clock derived from a stable external reference oscillator. Thus the data and clock presented to the DAC are de-coupled from the jittery data source over the S/pdif protocol ( this is basically my understanding of Ultralock ).
It seems to me that any device inserted in the s/pdif chain as an intermediate step (between the SB3 and DAC1) is made irrelevant by this (the DAC1's) particular hardware architecture. The selected devices (particularly the SRC) in the DAC1 already offer asynchronous FIFOs.
It's not like anything done to the spdif signal can stop or change this ultralock process from happening. It IS the hardware.

I am probably missing something in my description as I have cobbled it together from existing literature and do not have the source schematics.

Kana813 wrote:
"Right now, I wonder if a SB3(16/44.1)running through your Pacecar sounds any better than a SB3 running through an old Genesis Digital Lens(available here on audiogon for less than $500.). I'd be happy to test this for you."

I'll guarantee 100% that it does. The Pace-Car has an I2S output, which has much lower jitter than any S/PDIF output. It also uses Superclock4 or Ultraclock, which are lower jitter clocks.

I wish I had extra Pace-Cars and SB3's to lend them out, but I dont. If I get a request from a reviewer, maybe I'll build another set for demo, but he has to be the right reviewer.

Steve N.

Steve N.

The answer is that the asynchronous sample-rate conversion does make the DAC somewhat immune to incoming jitter, but not completely. You can test this for yourself by using a really cheap S/PDIF cable to it and then a really good one. If your system is resolving you should hear a difference, I do. Whe I drive the DAC-1 from a transport and then from an Off-Ramp USB-to-S/PDIF converter, the difference is obvious to me.

However, in your case, your money is probably better spent on upgrading the upsampling clock in the DAC-1 to something with lower jitter. Even with ultra-low jitter on the incoming S/PDIF signal, the upsampling clock will add its own jitter, and this is the final step in the chain. Improving the input jitter without improving this clock first is not recommended.

Steve N.
Empirical Audio

BTW, the Sonos isn't perfect either. I have been running one for days through my Pace-Car directly network-wired with superb results, but this morning I awoke to a screen with stripes through it and the mouse unresponsive. It was still playing music properly though. I had to power down and back up to fix it. It did not corrupt data on the disk, so no harm done.

Steve N.

Thanks Steve.
I thought (from the data sheet and the DAC1 implemenation) the SRC chip keeps the two clocks separate, though: 1) The serial data side (most jitter), and 2)on board 20 something MHz crystal,the clk signal of which is fed to the SRC side, AND the DAC. Are you saying that the crystal itself is now adding to the jitter equation, or that the frequency synthesis taking place inside the SRC chip, (the source of which is the crystal) is adding the jitter?
Thanks Much