World's first DIY Word Clock DAC

[wayne325]

So... it took a few months, and it's not in its case yet nor is the PS
made.

I believe I'm hearing for the first time, the first amateur-made DAC which will output a
word clock to a Transporter and then feed that clock directly to the DAC
chips.

I measured the 96 kHz reference at 95999.40 Hz yesterday. The clock
spectrum is very narrow.

I've not yet listened to CD input... but Dave's True Story, downloaded from
HDtracks sounds very very very good.

Off to listen now.

Hey Sean, that was a great idea.... thanks.

Hey how do I embed pics in posts ???? I suppose everyone wants to see
what a mess I've created.

[Phil Leigh]

How will it handle tracks with different clock rates (44.1/48/88.2/96) ?

[wayne325]

How will it handle tracks with different clock rates (44.1/48/88.2/96) ?

Here's the basic rundown:
DIR9001 receiver chip
SRC4192 SRC chip
PCM1704 DAC chips (4 - 2 per channel inverting and non-inverting)
discrete JFET I/V and buffers
2 clock sources - 11.2896 and 24.576 MHz
There are 3 gound planes - digital/2 analog
The only digital circuits in the analog section are the DAC chips themselves
and read side of isolator chips - each chip has its own linear supply.
I think there are 15 linear regulators and 6 or 7 power supply filters
in the whole DAC.

So now to answer the question. THere is a Xilinx Coolrunner II CPLD
that is the central clearinghouse for all the digital signals. It does

input data switching
clock switching
C-channel processing (only clock rate is used)
U-channel processing (none, but it's connected)
clock divider for word clock based on clock rate
input controls (source switch, clock switch)
output LED drivers (about 16 or so LEDs I think)

The sample rate of the signal is contained in the C-channel. The CPLD
captures this and based on the value it sees, performs the clock switch
and correct divide for 44.1/48/88.2/96 kHz. If the C-channel is not there,
the clock divide can be manually set from the front panel. Since there
is an SRC chip which always receives a clock, there will always be music.
It may not be ideal until a manual switch if auto is not correct, but the
DAC always makes music. The default clock is 96 kHz but I think I need
to change this because for things like internet radio, the sample rate is
44.1 kHz coming from the Transporter.

The good thing about the CPLD is that the design paradigm is software. If
there is a problem or I want to change how something behaves, I just change
the source code and download the new behaviour into the device. As long as
there is connectivity on the PCB to do what I want, I'm good to go.

I've yet to test the auto switching since I've not connected the input
control yet. But I have been able to change the word clock output between
44.1 / 96 by changing the CPLD code initial state and I can see that both
work with the Transporter just fine. Playing a CD source file when the clock
is at hi-res or vice versa results in quite comical sounds coming from the
stereo... so I know the word clock is being used. THat, and if the clock is
disconnected, the music abruptly stops.

Since the input SRC data rate is exactly equal to the SRC output rate, the
SRC is really not acting like an SRC.... it's just a digital filter.

I've done more listening yesterday. The thing that really stands out is the
kind of thing that digital is worst at. Things like high-hats and cymbals
and the like - high frequencies. Well-recorded discs sound really good.
Soundstaging is much improved and detail springs to life.

I can't form an opinion of the 96/24 though. The only music I've got in
hi-res, I've never heard in low-res (ie Redbook CD). It does sound very
clear though.

[wayne325]

I tried another way to get the auto switching to work, but it's not doing
the right thing. I guess first I'll run a sim and see if I've got a timing
bug and I can also have a look using the LEDs to tell me what the state
info is and see if I can debug that way. Nothing to worry about, for now
I'll do manual switches by changing CPLD code or inputs when I get those
connected.

[jacobdp]

Nice!

Now go get yourself a PMD200 :P

[wayne325]

Nice!

Now go get yourself a PMD200 :P

I looked at that as an option while doing the plan, they appear to be made
from Unobtainium. At least I couldn't find any for sale. All I could find
was people who struck out trying to find them. Anyhow it doesn't really
matter that much; I've got hundreds of CDs and exactly two of them are
HDCD encoded. And 192 kHz is of no advantage now, as there appears to be
no 192 kHz source material... although there is plenty of 88.2 / 96 kHz
stuff out there (which my DAC does play) and increasing all the time.

Anyhow, it's no matter.

This DAC is called DAC1 and it's already pretty much state of the art even
though it's made of easily obtained parts. The next one I make
will be more... sophisticated.

[ar-t]

I measured the 96 kHz reference at 95999.40 Hz yesterday. The clock
spectrum is very narrow.

Might I inquire as to what you consider to be "very narrow", and you determined that.

Pat

[earwaxer]

This word clock thing is interesting. I'm sure its something worth doing or they would not have put the input on the transporter! Could you please explain it! I guess what I am trying to understand is - What additional advantage would there be in inputting the word clock from an external dac vs. the way ethernet or wifi handles the clocking (with the clock being asynchronously reconstructed at the dac receiver) - I'm probably not getting it right! - thanks much!

[Phil Leigh]

This word clock thing is interesting. I'm sure its something worth doing or they would not have put the input on the transporter! Could you please explain it! I guess what I am trying to understand is - What additional advantage would there be in inputting the word clock from an external dac vs. the way ethernet or wifi handles the clocking (with the clock being asynchronously reconstructed at the dac receiver) - I'm probably not getting it right! - thanks much!

Er...yeah ... not right :-)
The Ethernet/Wi-Fi is out of the equation. The issue here is the communication between the transport (e.g. Transporter, SB3 etc - not the PC server!!) and an external DAC, via the s/pdif connection.

The issue with s/pdif (and AES/EBU) is that it combines both the digital information AND the transport clock. The clock needs to be recovered by the DAC. This recovery process can be imperfect and induce jitter.

A MUCH better method is for the clock in the DAC to act as the master clock and to drive the transport, but this requires several things:
1) The DAC has to have a clock out that can automatically change to the correct rate when it detects the transport sending it different bitrate files. Once locked (very quickly) to the correct rate for the PCM stream, the DAC clock then "takes over" control of the entire process.
2) The transport has to have a clock in.
3) An extra cable is required between transport and DAC.

This method will minimise jitter.

To be clear, PC-to-transport is asych / not a problem, Transport-to-DAC is sycnhronous / a problem.

[wayne325]

On the last question, Phil nailed it. One thing I would add. In my setup that
uses the word clock in, cables are no longer a factor. If I spend 10 cents
on a cable or $100,000 on a cable, the result is identical, so long as the
10 cent cable allows correct delivery of each bit. Anyone who would
listen and say they can hear a difference would be "exagerating" his ability
to tell a difference. So, I use $5 75 ohm BNC cables from Digikey. :-)
(Phil said a down-side is that you ned 2 cables - I'm just pointing out that
they needn't be $200 cables to get 100% of the potential performance and
in fact a very cheap cable can give you 100% of the potential performance)

On the clock, you can probe in various places and look at the spectrum on
a piece of test equipment called a Spectrum Analyzer. It draws a frequency
domain plot of energy vs frequency. You can see then where the energy is
down 10 dB or 50 dB or whatever. I didn't print a plot so I don't have
the exact numbers.

i don't have any equipment that tells me that the jitter spectrum is. It should be
very low though - I'd guess well below 50 ps because of all the regulators,
proper ground planes, decoupling, and split supplies. Oh, and the XTAL is
about 20 ps jitter on its own.

I also have the ability to turn off the unused clock, so there is no
note from the unused clock throwing jitter into the works.

W.