Computer Audio Asylum Music servers and other computer based digital audio technologies.

---

[ Follow Ups ] [ Post Followup ] Thread: [ Display  All  Email ] [ Computer Audio Asylum ]

---

[ Alert Moderator ]

---

My experience implementing John Swenson's Synch Reclocking Circuit for Squeezebox (long)

Posted by RioTubes (A) on October 1, 2007 at 11:50:37

Before going into the details below, the goal of this project was three-fold: (a) implement a high performance transport for my TDA1541 DAC, (b) eliminate the SPDIF interface and (c) minimize jitter at the DAC chip. This entailed modifying a Squeezebox to restrict but materially improve its function as a transport. This modified transport is able to accept a high quality 11.2896 MHz master clock and then output signals (BCK, LRCK and SDATA) via left justified format (i.e. the “paternal twin” of I2S so to speak) to an external DAC where the signals are reclocked/resynched just before D-to-A conversion.

John Swenson was generous in posting a schematic on Slim Devices’ audiophile forum for a Synchronous Reclocking circuit with the following characteristics and design goals:

• Intended to be located in an external DAC as close as possible to clock input pins of the dac chip
• The “heart” of the circuit is a high quality 11.2896 Mhz XO clock
• The master clock is sent to a Squeezebox in lieu of its existing 11.2896 Mhz crystal
• The BCK, LRCK and SDATA are intercepted in the Squeezebox and re-routed to the reclocking circuit in the external DAC via SB’s native Left Justified Format (similar to I2S)
• The reclocking circuit converts the signal to I2S, reclocks/resynchs the signals using the same XO and outputs BCK, LRCK and SDATA to the respective DAC pins.
• This circuit is specifically designed to accept Left Justified Format but output I2S format and should only be used in this context.

What this accomplishes is a reduction of jitter to extremely low levels where it matters most…at the DAC input pins. I think I recall John stating that the jitter measured lower than his scope is capable of detecting but that jitter is essentially limited to the spec of the XO used. John’ states: “the spectrum of the signals feeding the DAC are almost identical with that of the clock itself (essentially a flat line).” I used a Tent XO and the website states: “potentially < 3ps rms (10 Hz onwards) depending on power supply noise”. My current implementation would surely measure higher because I have not yet replaced with stock power supply.

This design resonated with me after reading several old posts by others—and, of significance to me, by Guido Tent—regarding the merits of sending a master clock from one’s DAC to a traditional CD transport, and transmitting signals via I2S back to the DAC where they are synchronously reclocked proximate to the dac’s input pins. Of course there are asynchronous reclocking circuit designs whose goal is to minimize jitter, and it’s above my pay grade to debate superiority of one versus others. So, John’s design takes a “tried and true” reclocking circuit and implements it in the context of a computer-based transport.

I am very appreciative of John for designing a circuit using parts that can be soldered using point-to-point wiring by an intermediate DIY’r *and* still result in a stellar improvement over more expensive commercial transports. I suspect that if John had build this, he would have implemented it via a multi-layer PCB with tiny SMD picogates instead of the larger DIP 74HC series flip flops that are easier to solder onto. In other words, I have built a modest circuit that would undoubtedly be executed better by advanced DIY’r and Digital Engineers, but the circuit is nonetheless very effective.

Outside of the reclocking circuit, there are a few areas of improvement I have yet to focus on:
• replacing the stock power supply
• really focusing on the cabling and connections to reduce EMI/RF
• reboxing the Squeezebox board in an enclosure that will reduce EMI/RF

Yet, even lacking these improvements, the above modifications result in the best digital I have experienced in my system. This is what I hear:

• a very relaxing sound. A reduction in glare and HF artifacts
• yet, at the same time, higher resolution
• quieter background
• due to the lower resolution floor, more nuanced and textured notes
• increased separation in instrumental notes
• able to hear ambient cues and can detect subtleties of the recording venue
• improved vocals

This project breaks down into 3 distinct parts:
• Building the reclocking circuit. There are not so many parts but the routing and soldering the 30awg wrap wire is time-consuming, challenging and tedious.
• Two mods to my DAC: (a) defeating the SPDIF interface and (b) soldering the output I2S cable from the new reclocking board (shielded FEP CAT 5) to a header on the DAC board that has traces leading to the appropriate dac chip input pins.
• Two mods to the SB: (a) removing the existing 11.2896 Mhz crystal and soldering the MCLK input wire to the vacated solder pad and (b) soldering 30awg wrap wire to each of the “dac side” resistor leads going into the BCK, LRCK and SDATA input pins of the SB’s dac chip.

Hence, there are three areas where things can go awry. I experienced an uncharacteristic stroke of genuine luck in pulling this off on the first attempt. The prospect of having to troubleshoot this project is nothing short of dreadful.

This was not a dirt cheap project, but probably about $150 or so, much of which went towards a Tent Shunt Regulator to power the reclocking circuit and a Tent XO as well as some bare silver wire I used for the ground and power supply rails.

Because the audio industry is so wonderfully fragmented with boutique and specialized offerings, and because our personal needs are so different, there are a zillion different ways to go in putting a system together. My specific goal was to develop a high quality, bare bones computer-based transport for my TDA1541 I2S DAC in a 2-channel context. I was set to implement an USB interface. However, after reading John’s and others experience that results of USB implementations varied depending on the quality, operation and location of the server and USB cable, I decided to opt for an Ethernet SB interface which has been reported to be virtually immune to differences in the quality and operation of the server. I’m not knocking the USB approach nor am I suggesting that it cannot approach or exceed the quality of an Ethernet-based transport, only reflecting that there appear to be more variables to address and optimize.

I have not had broad experience with different transports. This project has helped me to experience the benefits offered by a better transport. I have a CD player and a separate DAC that both use the ubiquitous 7308/6922-based output stages. The DAC is NOS while the CDP can be configured to use asynchronous upsampling. While using the CDP as a transport, the DAC was less resolving versus the stand-alone CDP, but the gap was reduced by installing CREE Schottky diodes in the DAC. The modified SB transport has taken the DAC to an entirely new level relative to the stand alone CDP. The DAC renders a more relaxed sound, but is also more resolving.

I offer my experiences in the context of someone whose day-to-day experience is limited to affordable gear (no single piece cost over $2K to make or buy) so consider my observations in this light.

Finally, I want to thank John Swenson for his help along the way. I find that his posts here and elsewhere are educational and practical for those of us enjoying this DIY hobby on our journey to more engaging musical playback. Thanks John!

This post is made possible by the generous support of people like you and our sponsors:

Parts Connexion

---

[ Top of Page ] [ Contact Us ] [ Support/Wish List ] [ Copyright © 2025, Audio Asylum, all rights reserved ]

---

[ General ] [ Speakers ] [ Tubes ] [ Vinyl ] [ Digital ] [ Hi-Rez ] [ Video Asylum ] [ Cables ] [ Tweaks/DIY ] [ Music ] [ Films ]

---