Slaving audio board with MCK on the DAC via SPDIF

[1audio]

I'm doing similar- the Juli@ card on a fanless Via. The Linux driver for the Juli@ card seems to work very well.

I will be making a commercial product around this with a special card hooked into the Juli@ interfaces etc. But the rest will be based on linux and mpd stuff.

 

[jkeny]

I just saw John Swenson's post about a new DAC he & Paul Joppa have developed which follows the same synchronous clocking concept and uses an FPGA to sense the audio stream clock.

Interestingly, he found that when used with an unsynched source (this is asynchronous reclocking) it worked very well: http://www.audioasylum.com/forums/bottlehead/messages/137092.html

I got all this working and decided to try it out on a S/PDIF stream that was NOT synced to the local clock. I was expecting to hear an occasional pop or click due to duplicated or dropped samples. To my surprise I found that I could hear no sonic impact at all from the non-synced input. It actually sounds great hooked up to a CD player or DVD player. Its not supposed to do that but for some reason it does. Now this needs a lot more experimentation but at least with the quick and dirty tests I did you just might be able to get away with an un-synced source.

So, two thing:
- is synchronous clocking really needed?
- getting rid of the SPDIF receiver & doing it with FPGA for PLL recovery is claimed to reduce the perturbation effects on the local clock

 

[1audio]

They are emulating an SPDIF receiver in the fpga. The receiver needs to decode the stream, which means finding the clock edges, the audio frames (word clock), the data in the frames and putting it together in the right order and in sync with mclk, bit clock and word clock. The fpga needs to do some sort of pll unless the two clocks are close enough, then it only needs to phase lock so it can get good data.

Running completely asyncronous should have a periodic burst of bad data. It may be possible to move the sync point at the beginning and even set up the fpga to drop a word when its bad. You would then need to fill in the gap, possibly with the previous word.

Its possible, but difficult to get two clocks to be within 1 ppm, that would mean possibly one glitch every million samples. It may be possible to have that inaudible.

The Lavry works similarly with its clock getting bumped up and down periodically to stay on track.

 

[jkeny]

Demian,
Reading what John S has done, it shows that in running his FPGA DAC with unsynched sources (CD or DVD) he seemed not to experience any dropped bits (pops or clicks).

Let's safely assume that the two free running clocks are not within 1ppm of each other then this is interesting, as theory would predict that he should hear problems. So what else is at play here?

Also, using a FPGA to recover the SPDIF stream apparently has advantages over using a SPDIF receiver chip in that it radiates less PS disturbance & therefore causes less jitter at the local clock

the correlated jitter from the PLL manages to work its way into the DAC, usually through noise on the ground connections. I spent a lot of effort with ground planes, multiple high quality regulators etc and still could not keep the PLL jitter completely out of the DAC.

 

[jkeny]

Another quote from John S that supports getting rid of a SPDIF receiver:

What I have discovered is that yes the incoming S/PDIF stream CAN affect the jitter even in a synchronous slaved system. An even when using optical connections.

You are correct in your assumption, the PLL is the culprit. I've done some spectrum analysis of the clocks and there is a very specific spectrum that comes out of S/PDIF recivers. Not only can you see this on the clock signal but the ground and PS as well. If you have a traditional S/PDIF PLL based receiver sending the data to the reclocker you can still see that signature on the clock going to DAC.

 

[1audio]

Interesting. I would like to see how to duplicate his measurements. Getting good measurements of this stuff is very difficult. Isolating noise sensitive stuff from noisy parts is also difficult. PlLs are potentially very noise sensitive since we are looking for 120 to 160 dB SN ratios.

If there is a signature of SPDIF noise spectrum that would also be interesting to see. There is a well known "interface induced jitter" problem with SPDIF but the normal understanding it that it can be reduced. It is data dependent and changes with the data. The other issue mentioned- that the jitter in the incoming datastream can pass through even with a DAC derived clock suggests inadequate isolation of the clock and management of the clock signals. This is a well known issue and there are accepted techniques for addressing the problem. They are used in the precision time measurement stuff.

 

[anbello]

interface bug fixed

I have recently used the interface as visualized in post #1 on this 24 bit DAC based on CS4398 and found a bug in my interface.
The interface works well with a 16 bit DAC based on TDA1543 but with the new 24 bit DAC i get a hugely attenuated analog out.
I fixed the problem using MCK instead of MCK/2 to reclock the BCK, WS and DATA lines.
I attach the schematic with the fix.

Ciao
Andrea

 

[anbello]

I also did some measures on this new DAC to see the FFT of the Jtest signal in two cases: 1) using the onboard CS8416 as spdif receiver and 2) using my slaving interface bypassing the CS8416.
For now i don't have any good image to show (i did the measures on late night) but i can describe what i remember (i visualized the FFT with 11025Hz on center band and near +/- 4000Hz on each side):
case 1) the noise floor around the center peak near -95db
case 2) the noise floor around the center peak near -110db

This is only preliminary test and i used an inapprapriate software to see the FFT (i cannot change the number of samples nor the window).
I would like to repeat the measures using the hints in this article
http://www.msbtech.com/support/JitterPaper.pdf
to obtain more meaningful results to share.

Ciao
Adrea