OK, I've read the posts regarding just transfering the direct I2S lines from the decoder via some coax cables. This has merit, but I'd like to try to go another direction with reducing the jitter problems associated with SPDIF.
Elso, you have noted that (for example) the PCM1716 datasheet states that it can be used with an independent "stand alone" crystal oscillator. You further note that most delta-sigma DAC's are capable of this as well... and I've read this now a few additional places.
I have some questions regarding this:
1. I'm assuming that by creating a new master clock, one would also clock-divide this to produce the bit clock and word clocks... so that they are all syncronous to each other. Correct assumption?
2. How can one have the data line itself asynchronous to the clocking lines?
3. Wouldn't the data line itself have some inherent jitter in it as well?
4. Would a delay of some sort need to be added to the master clock to keep it in sync with the clock-divided bit and word clocks?
5. Does anyone have a simplfied conceptual diagram of this type of topology?
Many thanks for your thoughts...
Elso, you have noted that (for example) the PCM1716 datasheet states that it can be used with an independent "stand alone" crystal oscillator. You further note that most delta-sigma DAC's are capable of this as well... and I've read this now a few additional places.
I have some questions regarding this:
1. I'm assuming that by creating a new master clock, one would also clock-divide this to produce the bit clock and word clocks... so that they are all syncronous to each other. Correct assumption?
2. How can one have the data line itself asynchronous to the clocking lines?
3. Wouldn't the data line itself have some inherent jitter in it as well?
4. Would a delay of some sort need to be added to the master clock to keep it in sync with the clock-divided bit and word clocks?
5. Does anyone have a simplfied conceptual diagram of this type of topology?
Many thanks for your thoughts...
Tieftoener said:
Hi Tieftoner,
Ough, a lot of intrigueing questions I hardly know the answer of.
First let me say it was just an idea to use an asynchronous clock with a Delta-sigma DAC. I do not have such a DAC so I will not perform this experiment. I am not aware of the inwards of the chip of a deltasigma dac and digital filter. Maybe the synchronizing is just done as in my asynchronous recloker with two flip-flops in series or even with a more sophisticated scheme as found on the net.
So quite frankly I do not know. Just try it and see if it works.
For me the best appoach seems to be not to mess around with the digital signals hence the I2S direct idea. Not invented by me, but Audio Alchemy, Sonic Frontiers, Northstar and others are using it.
How to (almost) elmiminate the jitter problem
To adress the jitter problem, you have to know which clock signal of your DAC is responsible for the actual change of the analog output signal between two samples. I'm using the PCM1704 and for this chip it is the bit clock signal. For you, this might be a different signal, but it is not the data line. See the datasheet of your chip.
If you get this clock signal as low-jitter and clean as possible, the jitter problem is almost eliminated as timing inaccuracies of the other clock or data lines won't show up at the analog output of the DAC. To further isolate clock signals from the DAC and analog circuitry, it is a big advantage to have dedicated clock, digital and analog power supplies. The grouding scheme is also very important.
This approach implies a local, independent clock source near the DAC. To resolve the synchronization problem, either clock the digital source (CD transport or whatever) from this local oscillator, or, if you're using S/PDIF, use an ASRC at the input of the DAC.
My digital preamp uses a CS8420 ASRC, DF1704 digital filter and PCM1704 DAC chipset. The bit clock of the PCM1704 is directly driven from the Kwak clock, the rest of the circuit gets the inverted output of the Kwak clock. This setup sounds excellent and you can hear almost no difference whether the digital source is a high quality CD transport or a cheap computer CD-ROM drive.
To adress the jitter problem, you have to know which clock signal of your DAC is responsible for the actual change of the analog output signal between two samples. I'm using the PCM1704 and for this chip it is the bit clock signal. For you, this might be a different signal, but it is not the data line. See the datasheet of your chip.
If you get this clock signal as low-jitter and clean as possible, the jitter problem is almost eliminated as timing inaccuracies of the other clock or data lines won't show up at the analog output of the DAC. To further isolate clock signals from the DAC and analog circuitry, it is a big advantage to have dedicated clock, digital and analog power supplies. The grouding scheme is also very important.
This approach implies a local, independent clock source near the DAC. To resolve the synchronization problem, either clock the digital source (CD transport or whatever) from this local oscillator, or, if you're using S/PDIF, use an ASRC at the input of the DAC.
My digital preamp uses a CS8420 ASRC, DF1704 digital filter and PCM1704 DAC chipset. The bit clock of the PCM1704 is directly driven from the Kwak clock, the rest of the circuit gets the inverted output of the Kwak clock. This setup sounds excellent and you can hear almost no difference whether the digital source is a high quality CD transport or a cheap computer CD-ROM drive.
AMT-freak,
Thanks, that's some VERY helpful information... and very (obviously) good point about the bit clock moving the analog signal value. I'll be sure to double check the datasheet on the DAC I choose to use (most likely going to be the CS4396 at this point).
All along, I've been trying to figure out how to integrate the Kwak Clock to an external DAC... and this now alleviates some major issues. And it even makes sense
You say that the bit clock of the PCM1704 DAC is fed directly from the output of the Kwak clock... but what feeds the input of the Kwak clock? The bit clock output of the DF1704?
How do you dirive the word clock? Clock divide the Kwack clock output?
What do you mean by: "...the rest of the circuit gets the inverted output of the Kwak clock."????
Sorry about the many questions - I'm just trying to understand
Thanks, that's some VERY helpful information... and very (obviously) good point about the bit clock moving the analog signal value. I'll be sure to double check the datasheet on the DAC I choose to use (most likely going to be the CS4396 at this point).
All along, I've been trying to figure out how to integrate the Kwak Clock to an external DAC... and this now alleviates some major issues. And it even makes sense
You say that the bit clock of the PCM1704 DAC is fed directly from the output of the Kwak clock... but what feeds the input of the Kwak clock? The bit clock output of the DF1704?
How do you dirive the word clock? Clock divide the Kwack clock output?
What do you mean by: "...the rest of the circuit gets the inverted output of the Kwak clock."????
Sorry about the many questions - I'm just trying to understand
Sorry about not being clear.
The CS8420 decouples input (S/PDIF) and output (I2S) clocks completely. No matter what input sampling frequency the CS8420 receives via its S/PDIF input, it will output 96 kHz I2S signals. To achieve this, it needs an independant 24.576 MHz input clock (256 x sampling frequency).
To generate this clock signal, I use the Kwak clock with a fundamental mode 24.576 MHz crystal. The Kwak clock has no input as such besides power supply, as all circuitry after the CS8420 is asynchronous to and independant from the input signal's clock and timing.
The standard approach would be to feed the CS8420 output signals to the DF1704 (glueless interfacing possible) and from there to the two (or four in my DAC) PCM1704s. Both CS8420 and DF1704 would be clocked from the Kwak clock output. This way, the low-jitter Kwak clock signal would pass through a couple of gates in the DF1704 before entering the PCM1704.
However, by a very helpful coincidence, the bit clock of the PCM1704 in my application is also 256 x fs = 24.576 MHz. So I simply leave the DF1704's bit clock output alone and instead directly connect the Kwak clock's output to my DACs, shortening the clock signal path and bypassing some gates. The word clock still comes from the DF1704, but as mentioned in the previous post, it will not affect the timing of the analog output. There is only one caveat: To synchronize the parts properly, CS8420 and DF1704 need a clock signal of inverse polarity compared to the PCM1704. This is no problem at all as the Kwak clock has inverting and non-inverting outputs anyway.
My scanner is not working properly at the moment, but if more clarifaction is needed, I will draw a simplified schematic and try to post it somehow.
Feeding the DAC's bitclock directly from a low jitter clock with separate power supplies is about the best you can achieve. There is one problem though. The ASCR will not output exactly the same digital signal that is read from CD or DVD (obviously when input and output sampling rate differ, but also when input and output clocks are out of sync).
BTW, the designer of the JISCO device mentioned in another thread claims that ASCRs super-impose the transport's jitter on the digital signal, a claim which I do not agree to, but that's a different matter. The statement probably helps to sell a couple of logic chips for 500 bucks
Jisco thread is here:
http://www.diyaudio.com/forums/showthread.php?s=&threadid=21832
The CS8420 decouples input (S/PDIF) and output (I2S) clocks completely. No matter what input sampling frequency the CS8420 receives via its S/PDIF input, it will output 96 kHz I2S signals. To achieve this, it needs an independant 24.576 MHz input clock (256 x sampling frequency).
To generate this clock signal, I use the Kwak clock with a fundamental mode 24.576 MHz crystal. The Kwak clock has no input as such besides power supply, as all circuitry after the CS8420 is asynchronous to and independant from the input signal's clock and timing.
The standard approach would be to feed the CS8420 output signals to the DF1704 (glueless interfacing possible) and from there to the two (or four in my DAC) PCM1704s. Both CS8420 and DF1704 would be clocked from the Kwak clock output. This way, the low-jitter Kwak clock signal would pass through a couple of gates in the DF1704 before entering the PCM1704.
However, by a very helpful coincidence, the bit clock of the PCM1704 in my application is also 256 x fs = 24.576 MHz. So I simply leave the DF1704's bit clock output alone and instead directly connect the Kwak clock's output to my DACs, shortening the clock signal path and bypassing some gates. The word clock still comes from the DF1704, but as mentioned in the previous post, it will not affect the timing of the analog output. There is only one caveat: To synchronize the parts properly, CS8420 and DF1704 need a clock signal of inverse polarity compared to the PCM1704. This is no problem at all as the Kwak clock has inverting and non-inverting outputs anyway.
My scanner is not working properly at the moment, but if more clarifaction is needed, I will draw a simplified schematic and try to post it somehow.
Feeding the DAC's bitclock directly from a low jitter clock with separate power supplies is about the best you can achieve. There is one problem though. The ASCR will not output exactly the same digital signal that is read from CD or DVD (obviously when input and output sampling rate differ, but also when input and output clocks are out of sync).
BTW, the designer of the JISCO device mentioned in another thread claims that ASCRs super-impose the transport's jitter on the digital signal, a claim which I do not agree to, but that's a different matter. The statement probably helps to sell a couple of logic chips for 500 bucks
Jisco thread is here:
http://www.diyaudio.com/forums/showthread.php?s=&threadid=21832
I'm going through the CS8414 DIR spec sheet again, as I already have 5 or 6 of them, so my first DAC is going to use it. I can always make improvements later, which I most certainly WILL do
I have had a revalation... perhaps
First off, Cirrus likes to call the bit clock "SCK". I was looking at the Crystal CDB4396 (eval board for CS4396/7 DACs) as a reference for designing my version, and realized that they don't have any reset switch setup for the CS8414 on board. This lead me to the CS8414 data sheet. To put the CS8414 in reset, one has to put all four mode pins (M3-M0) high. In looking further at the "special modes" table, there is a mode for using an Asyncronous SCK input. "INTERESTING..." I thought outloud...
Does this mean that I could send a low jitter SCK source (Kwak clock) in to the SCK of the CS8414??... thus giving me the ability to use SPDIF, and readily get a low jitter signal to send to the DAC? On page 21 of the data sheet, it describes this mode as format 11, saying:
Say, I just want this outboard DAC to decode red-book CD standard, is there any reason I couldn't generate a low-jitter bit-clock (SCK) for a 44.1kHz fs? I'm assuming this would just be the standard 256fs, thus 11.2896MHz. In my head, this seems to make sense. I'm just confused as to why they first say that the FSYNC and SDATA are synchronized to the incoming SCK, but then they say that there will be a varying amount SCK periods between FSYNC edges. That doesn't make sense to me...
Any help would be greatly appreciated!! Thanks,
I have had a revalation... perhaps
First off, Cirrus likes to call the bit clock "SCK". I was looking at the Crystal CDB4396 (eval board for CS4396/7 DACs) as a reference for designing my version, and realized that they don't have any reset switch setup for the CS8414 on board. This lead me to the CS8414 data sheet. To put the CS8414 in reset, one has to put all four mode pins (M3-M0) high. In looking further at the "special modes" table, there is a mode for using an Asyncronous SCK input. "INTERESTING..." I thought outloud...
Does this mean that I could send a low jitter SCK source (Kwak clock) in to the SCK of the CS8414??... thus giving me the ability to use SPDIF, and readily get a low jitter signal to send to the DAC? On page 21 of the data sheet, it describes this mode as format 11, saying:
Say, I just want this outboard DAC to decode red-book CD standard, is there any reason I couldn't generate a low-jitter bit-clock (SCK) for a 44.1kHz fs? I'm assuming this would just be the standard 256fs, thus 11.2896MHz. In my head, this seems to make sense. I'm just confused as to why they first say that the FSYNC and SDATA are synchronized to the incoming SCK, but then they say that there will be a varying amount SCK periods between FSYNC edges. That doesn't make sense to me...
Any help would be greatly appreciated!! Thanks,
Individual coming from Mars
Hi Tieftoner,
These Cirrus/Crystal datasheets are wrote by a individual coming from Mars. Totally incomprehensible.
I have good reason to believe Doede is right but I prefer I2S direct as we omit a lot of messing around with digital signals.
Tieftoener said:I'm going through the CS8414 DIR spec sheet again, as I already have 5 or 6 of them, so my first DAC is going to use it. I can always make improvements later, which I most certainly WILL do
I have had a revalation... perhaps
First off, Cirrus likes to call the bit clock "SCK". I was looking at the Crystal CDB4396 (eval board for CS4396/7 DACs) as a reference for designing my version, and realized that they don't have any reset switch setup for the CS8414 on board. This lead me to the CS8414 data sheet. To put the CS8414 in reset, one has to put all four mode pins (M3-M0) high. In looking further at the "special modes" table, there is a mode for using an Asyncronous SCK input. "INTERESTING..." I thought outloud...
Does this mean that I could send a low jitter SCK source (Kwak clock) in to the SCK of the CS8414??... thus giving me the ability to use SPDIF, and readily get a low jitter signal to send to the DAC? On page 21 of the data sheet, it describes this mode as format 11, saying:
Say, I just want this outboard DAC to decode red-book CD standard, is there any reason I couldn't generate a low-jitter bit-clock (SCK) for a 44.1kHz fs? I'm assuming this would just be the standard 256fs, thus 11.2896MHz. In my head, this seems to make sense. I'm just confused as to why they first say that the FSYNC and SDATA are synchronized to the incoming SCK, but then they say that there will be a varying amount SCK periods between FSYNC edges. That doesn't make sense to me...
Any help would be greatly appreciated!! Thanks,
Hi Tieftoner,
These Cirrus/Crystal datasheets are wrote by a individual coming from Mars. Totally incomprehensible.
I have good reason to believe Doede is right but I prefer I2S direct as we omit a lot of messing around with digital signals.
More about reducing jitter
Two address the jitter problem, there are five "standard" ways, all of which have been implemented commercially and DIY.
1.) Get rid of the problem right at the source, e.g. the player. The player and the DACs would be fed from the same local low-jitter clock. PSU design and clock distribution scheme would be optimized to have the lowest jitter possible at the DAC, while the jitter at the rest of the circuit isn't that important.
For external DACs, we either have to isolate the timing of incoming signal from the timing of the DAC chip, or recover the original clock better than usual.
2.) Design a high quality PLL which recovers the original clock better than a simple CS841x receiver chip. The Pass Labs D1 (service manual available from their site) is a nice example of a good implementation of this technique.
3.) Let the input data stream fill a FIFO buffer. The DAC is fed from a local low-jitter clock and the data comes from the buffer. Due to the separate transport and DAC clocks, the buffer will empty or fill up slowly, depending on which clock is faster. Thus, we must provide some means to slightly "tune" the local clock source to keep the buffer about half filled.
4.) Use an ASRC to complete isolate the timing of input data stream and DAC chip. This approach is cheap and easy, but there are some caveats.
5.) Asynchronous reclocking right before the DAC. A nice idea, cheap to implement and it works good.
@Tieftoener, unfortunately I don't think your idea will work, because the CS8414 neither contains memory nor an ASRC.
Two address the jitter problem, there are five "standard" ways, all of which have been implemented commercially and DIY.
1.) Get rid of the problem right at the source, e.g. the player. The player and the DACs would be fed from the same local low-jitter clock. PSU design and clock distribution scheme would be optimized to have the lowest jitter possible at the DAC, while the jitter at the rest of the circuit isn't that important.
For external DACs, we either have to isolate the timing of incoming signal from the timing of the DAC chip, or recover the original clock better than usual.
2.) Design a high quality PLL which recovers the original clock better than a simple CS841x receiver chip. The Pass Labs D1 (service manual available from their site) is a nice example of a good implementation of this technique.
3.) Let the input data stream fill a FIFO buffer. The DAC is fed from a local low-jitter clock and the data comes from the buffer. Due to the separate transport and DAC clocks, the buffer will empty or fill up slowly, depending on which clock is faster. Thus, we must provide some means to slightly "tune" the local clock source to keep the buffer about half filled.
4.) Use an ASRC to complete isolate the timing of input data stream and DAC chip. This approach is cheap and easy, but there are some caveats.
5.) Asynchronous reclocking right before the DAC. A nice idea, cheap to implement and it works good.
@Tieftoener, unfortunately I don't think your idea will work, because the CS8414 neither contains memory nor an ASRC.
Who the heck is "Deode" ?? Am I missing something?
AMT-Freak: Well, obviously, the mode itself has to work, otherwise it wouldn't be an option for the chip. The explanation of what the purpose would be is the confusing part - the data sheet says the technique would be good for "writing data to storage." Perhaps this implies putting it into a FIFO, as you metnioed earlier...?
And, secondly, I'm not talking about sample rate conversion. if the input from SPDIF is 44.1k fs, and you send an SCK for that particular sampling rate, then there's no need to convert the sample rate. I don't like SRC's when going to a non-integer multiple. Is it possible to SRC to say 88.2kHz with the CS8420 or the AD1892? That has some possibilities... A lot of the reason AC97 chipsets for computers are so poopy... everything's converted to 48kHz fs.... and also the reason for lazy "re-masters" of CD's to DVD-A's. 44.1kHz does not divide into 96kHz or 192kHz... I just don't get this type of thinking...
I'm aware of the options you list for jitter reduction... I hadn't compiled a list, but am familiar with each of the techniques. I'm basically trying to do the 5th technique as simply as possible, so this is why I'm asking such strange questions. Perhaps I am misunderstanding how it would be implemented. Is there an easy way?
many thanks to all
!
Tieftoener said:
That was my point. It will not work with a stand-alone clock in your DAC. You either have to synchronize them or a sample will be dropped from time to time. They'll neither be in phase nor have exactly the same frequency. You need a PLL or you have to take the asynchronous reclocking approach which uses a much higher frequency clock to "clean up" the transistion from "0" to "1" in the clock signals.
/AMT-freak - digging out the CS8414 datasheet
the confusion lies in the fact that the CS8414 data sheet says that the FSYNC and SDATA lines are synch'd to the incoming SCK.... which is what sparked my interest in the first place. It seemed to operate as an asynchronous receiver to me... sorry to be a pain - just trying to figure out what the heck those Crystal guys are thinking...
Thanks again for the help guys (and gals)
Thanks again for the help guys (and gals)
Yep, I found the paragraph you're referring to. It's in fact confusing.
There seems to be a mode in which you input SCK with the receiver chip providing sync'ed FSYNC and SDATA outputs. However, the same paragraph mentions that the number of SCK pulses per FSYNC will vary due to the receiver's input being asynchronous to the output. This situations is not desireable at all.
Still, I can't figure out how someone could build an asynchronous receiver without a buffer (and a means to avoid buffer over- and underflows) or an ASRC. There must be an error somewhere.
I'll have a closer look at the datasheet tomorrow. Somewhat tired right now. Maybe Jocko can jump in, he knows that chip and the reasons not to use it.
There seems to be a mode in which you input SCK with the receiver chip providing sync'ed FSYNC and SDATA outputs. However, the same paragraph mentions that the number of SCK pulses per FSYNC will vary due to the receiver's input being asynchronous to the output. This situations is not desireable at all.
Still, I can't figure out how someone could build an asynchronous receiver without a buffer (and a means to avoid buffer over- and underflows) or an ASRC. There must be an error somewhere.
I'll have a closer look at the datasheet tomorrow. Somewhat tired right now. Maybe Jocko can jump in, he knows that chip and the reasons not to use it.
Reasons for not using it:
Schmitt trigger inputs. If you must, put something between it and the line. It does work better differential.
BTW.....anyone try the TI DIR170x chip?? Been meaning to try my samples......for about a year now. Maybe I will try this weekend. They claim low jitter on recovered clock, but who knows unless we actually measure it. And I will, if I ever finish one. Stay tuned.
Jocko
Schmitt trigger inputs. If you must, put something between it and the line. It does work better differential.
BTW.....anyone try the TI DIR170x chip?? Been meaning to try my samples......for about a year now. Maybe I will try this weekend. They claim low jitter on recovered clock, but who knows unless we actually measure it. And I will, if I ever finish one. Stay tuned.
Jocko
well, i wanted to use the CS8414 because I had a bunch of them that i got during my senior design project, and also it's simplicity... ..... ..... that is up until i started asking all these questions
Jocko: Thanks, yeah, I remembered reading that you disliked the Schmitt trigger inptus - would you mind explaining why this is bad in practical terms to a virgin EE?
There's a DIY DAC on the Headwize website that is pretty intriguing: http://headwize2.powerpill.org/projects/ifkovic_prj.htm
He uses the DIR1703 and an AD1866 DAC on a DIY PCB layout... impressive for an SSOP package I am actually thinking of trying his little DAC/HP amp out. I can't find the EL2001 buffer anywhere, not even on the Elantec website. I've found several references to it on the web, but no datasheet or sources. Oh well... I'll just have to tweak and adapt - I would like to do my own discrete amp, something similar to the BOZ preamp.
Andrija notes the rated intrinsic receiver jitter specs as the reason for his choosing the DIR1703 over the CS841x... which really aren't that important since the jitter reduction rating in DIR's is usually well above audio bandwidth. Also, he mentions:
Well, I need to get back to another project - TTFN...
AMT-Freak: That's exactly what I was saying - what they say makes no sense. Initially, it provoked a lot of interest as it seemed that one could "reclock" the data and FSYNC to the SCK input without doing anything else... it seemed to easy. And then they go ahead and tell you that it will drop out from time to time right afterwards. Like you said, it's hard to imagine "asynchronous receiver without a buffer... or an ASRC." I'm right with you on that, but I wanted to see if there was something to what the data sheet was saying and if it had any merit.
Jocko: Thanks, yeah, I remembered reading that you disliked the Schmitt trigger inptus - would you mind explaining why this is bad in practical terms to a virgin EE?
There's a DIY DAC on the Headwize website that is pretty intriguing: http://headwize2.powerpill.org/projects/ifkovic_prj.htm
He uses the DIR1703 and an AD1866 DAC on a DIY PCB layout... impressive for an SSOP package
I am actually thinking of trying his little DAC/HP amp out. I can't find the EL2001 buffer anywhere, not even on the Elantec website. I've found several references to it on the web, but no datasheet or sources. Oh well... I'll just have to tweak and adapt - I would like to do my own discrete amp, something similar to the BOZ preamp.Andrija notes the rated intrinsic receiver jitter specs as the reason for his choosing the DIR1703 over the CS841x... which really aren't that important since the jitter reduction rating in DIR's is usually well above audio bandwidth. Also, he mentions:
I'm a bit confused, because all he did was to put some resistance (1k) in line with the output of the optical receiver to the input pin of the DIR1703. I've meant to email him regarding this, but haven't gotten to it.
Well, I need to get back to another project - TTFN...
Reclocking the CS8412
Hi Tieftoner,
Sorry I mixed up two threads.
I meant Doede Douma and this is his DAC:
http://www.dddac.de/ma_dac21.htm
Perhaps he is doing what you like to do.....
Tieftoener said:
Who the heck is "Deode" ?? Am I missing something?
many thanks to all
Hi Tieftoner,
Sorry I mixed up two threads.
I meant Doede Douma and this is his DAC:
http://www.dddac.de/ma_dac21.htm
Perhaps he is doing what you like to do.....
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.