hi
I added a few links to investigate some deeper into that topic
Proper word clock implementation:
http://recforums.prosoundweb.com/index.php/m/200173/0/
Clock and Jitter
http://www.kinotechnik.edis.at/pages/dcx2496/DCX2496/frandsen_2000_clock_synchr.pdf
Techniques of Measuring of High Speed Devices
http://www.kinotechnik.edis.at/pages/dcx2496/DCX2496/highspeed comperators_an13 (1).pdf
when I find the time but I am not sure to be able to set up the measurment for this right (see the link above).
greetings
Michael
I added a few links to investigate some deeper into that topic
Proper word clock implementation:
http://recforums.prosoundweb.com/index.php/m/200173/0/
Clock and Jitter
http://www.kinotechnik.edis.at/pages/dcx2496/DCX2496/frandsen_2000_clock_synchr.pdf
Techniques of Measuring of High Speed Devices
http://www.kinotechnik.edis.at/pages/dcx2496/DCX2496/highspeed comperators_an13 (1).pdf
when I find the time but I am not sure to be able to set up the measurment for this right (see the link above).
greetings
Michael
Hi Jan,
you are right, you can't take out the 110 ohm termination resistor while using a SPDIF cooper cable. But with an optical cable and a short cable between the converter (which is powered from the DCX supply) and the CS8420 this isn't an issue any more. See page 71 of CS8420 datasheet.
The optical cable has the big advantage that you are galvanically totally isolated including noise caused by the different PSUs and you do not need the transformer any more.
Michael,
beside your measurements I would expext some differences at 20Hz and 20kHz comparing analog and digital inputs due to an additional DAC and ADC with filters each. Although ADC and DAC are 24-bit types there should be differences in the last one or two bits (bit 14 and 15 based on 16-bit CD data) which most probably can't be heard.
regards,
Frank
you are right, you can't take out the 110 ohm termination resistor while using a SPDIF cooper cable. But with an optical cable and a short cable between the converter (which is powered from the DCX supply) and the CS8420 this isn't an issue any more. See page 71 of CS8420 datasheet.
The optical cable has the big advantage that you are galvanically totally isolated including noise caused by the different PSUs and you do not need the transformer any more.
Michael,
beside your measurements I would expext some differences at 20Hz and 20kHz comparing analog and digital inputs due to an additional DAC and ADC with filters each. Although ADC and DAC are 24-bit types there should be differences in the last one or two bits (bit 14 and 15 based on 16-bit CD data) which most probably can't be heard.
regards,
Frank
Hi Jan,
Hi Michael,
I tried to understand where the jitter in Michaels digital measurement comes from. My conclusion so far is that jitter isn't jitter.
1. There is jitter on the S/PDIF line because of noise, dalays or whatever. I think this is up to a certain level not the problem. Thats't because there is a PLL in the CS8420 which recovers the clock from the data stream. I think it's only important that the source of the S/PDIF sgnal has a stable clock at all, so that it doesn't go up and down.
2. The jitter Michael is measuring I think is coming from the fact that the transmitter (PC audio card) has a similar but different clock than the receiver (DCX DSP). That means that there must be some data over- oder underflow in the CS8420. The sample rate converter in the CS8420 has to handle this different input and output data rates, but I think this device can only minimize the problem but not completely solve it. The analog inputs don't have this problem, but on the other hand you get more noise.
So what's to do?
a, Use a better data recovery ciruit to minimize jitter (Which is realy better?).
b, To avoid this kind of jitter at all the only solution might be Big Ben. That means transmitter and receiver should have the same 24. 575 MHz crystal.
Might be that there are already solutions in this forum which I'm not aware of.
Jan,
the CS8420 data sheet tells me that it supports S/PDIF. What's the problem and how did you solve it? Perhaps you have a web link for me?
Kind Regards,
Frank
Hi Michael,
I tried to understand where the jitter in Michaels digital measurement comes from. My conclusion so far is that jitter isn't jitter.
1. There is jitter on the S/PDIF line because of noise, dalays or whatever. I think this is up to a certain level not the problem. Thats't because there is a PLL in the CS8420 which recovers the clock from the data stream. I think it's only important that the source of the S/PDIF sgnal has a stable clock at all, so that it doesn't go up and down.
2. The jitter Michael is measuring I think is coming from the fact that the transmitter (PC audio card) has a similar but different clock than the receiver (DCX DSP). That means that there must be some data over- oder underflow in the CS8420. The sample rate converter in the CS8420 has to handle this different input and output data rates, but I think this device can only minimize the problem but not completely solve it. The analog inputs don't have this problem, but on the other hand you get more noise.
So what's to do?
a, Use a better data recovery ciruit to minimize jitter (Which is realy better?).
b, To avoid this kind of jitter at all the only solution might be Big Ben. That means transmitter and receiver should have the same 24. 575 MHz crystal.
Might be that there are already solutions in this forum which I'm not aware of.
Jan,
the CS8420 data sheet tells me that it supports S/PDIF. What's the problem and how did you solve it? Perhaps you have a web link for me?
Kind Regards,
Frank
Hi
the more I read about this and the more I try to correlate with what I hear, the more I come to the point that distributing audio digitally needs either worldclock or for every singel device in the chain a close to perfect local clock.
Jitter introduced through cabels - and TOS Link seems to add even more - would make worldcklock the best solution, comparable to symmetrical signal routing in PRO audio versus singel ended in home HIFI.
Seen like this, the structure of the output board (AD diff > diff to singel > DC and HF filter and mute > singel to diff > XLR out) is highly professional by the way.
The digital input of the DCX has to convert the samplerate anyway (44,1kHz from CD to 96kHz DCX). This means that this point behaves like a conversion to analog and back to digital with all jitter imperfections of the source AND the DCX. I am not sure how clock restauartion works in detail and how effective it really is.
Yes I agree to some extent. Though the -3dB points are pretty far outside the 20-20kHz band. To me digital in DOES have tighter bass and even more detail, but all apears somehow brute and emty - not what I love on music.
Frank,
do you have pictures of your mod?
Greetings
Michael
the more I read about this and the more I try to correlate with what I hear, the more I come to the point that distributing audio digitally needs either worldclock or for every singel device in the chain a close to perfect local clock.
Jitter introduced through cabels - and TOS Link seems to add even more - would make worldcklock the best solution, comparable to symmetrical signal routing in PRO audio versus singel ended in home HIFI.
Seen like this, the structure of the output board (AD diff > diff to singel > DC and HF filter and mute > singel to diff > XLR out) is highly professional by the way.
The digital input of the DCX has to convert the samplerate anyway (44,1kHz from CD to 96kHz DCX). This means that this point behaves like a conversion to analog and back to digital with all jitter imperfections of the source AND the DCX. I am not sure how clock restauartion works in detail and how effective it really is.
Yes I agree to some extent. Though the -3dB points are pretty far outside the 20-20kHz band. To me digital in DOES have tighter bass and even more detail, but all apears somehow brute and emty - not what I love on music.
Frank,
do you have pictures of your mod?
Greetings
Michael
oettle said:
There's a wealth of info here (look in the files area):
http://tech.groups.yahoo.com/group/DCX2496/
Just register (free) as a member.
Jan Didden
mige0 said:
Yes indeed, that is what Master "clockmaker" Guido Tent was suggesting in his papers. The main clock suppose to be where DA conversion is happening and than separate wires should connect clock in your source in order to synchronize to each other. I remember reading about that on his site at one point in time:
http://www.tentlabs.com/index.html
yepp! but distributing a Mhz clock isn't that easy (and few device support superclock input anyway). Distributing 44.1k, 48k, 88.2k 96k, 176.4k, 192k just as needed dosn't sound less complicated AND you have to reley on the PLL of each device that recreates the masterclock again.
Yes, the ONYX 400F can be set to either of the above frequencies manually or can lock to extarnal Clock-Input or can lock to the SPDIF AES/EBU signal.
The measurements were taken in this last setting. You alwas have to keep in mind that theoretically you will not see any jitter if if the AD and DA conversion are done with the same jitter.
There is almost no jitter to see in my loop pictures for exactly that reason. The CD transport feeds its signal to the ONYX via SPDIF and the ONYX locks on the clock of the transport. Then I output (DA conversion) the signal to the XLR cable.
This signal carries the jitter of the transport clock and also the ONYX which is locked to that!
Then I am looping back to XLR input = AD of the ONYX and measure with appropriate software via the Firewire of the ONYX.
As signal generation and measurement was done within the same device the jitter of that device cancels out more or less.
maybe you are right - I am not an expert in all this.
To me breaking the loop with the DCX performing a DA conversion with the digital input in use should give the pure jitter response of the DCX.
On the other hand using the analog input in normal operation should have NO effect on sound depending on the jitter issue because the jitter cancellation should only appear when you go straight thrugh - and that is not what a x-over normally does.
I din't find articels that alow for calculation though.
greetings
Michael
Hi,
when using 44.1 kHz CD data only we shouldn't loose resolution when using a 11.29 MHz crystal (44.1 x 256) instead of the 24.567 MHz (96 x 256) crystal but probably win less jitter (which should be first double checked by Michael based on 48 or 96 kHz). This mod would only make sense with the digital input based on 44.1 kHz CD data. With the analog inputs I think it's better to stay with the 96kHz.
The next question would be where to get a 11.29 MHz crystal.
regards,
Frank
when using 44.1 kHz CD data only we shouldn't loose resolution when using a 11.29 MHz crystal (44.1 x 256) instead of the 24.567 MHz (96 x 256) crystal but probably win less jitter (which should be first double checked by Michael based on 48 or 96 kHz). This mod would only make sense with the digital input based on 44.1 kHz CD data. With the analog inputs I think it's better to stay with the 96kHz.
The next question would be where to get a 11.29 MHz crystal.
regards,
Frank
Michael,
Isn't there a possibility to connect your ONYX 400 via Firewire to the PC so that the output of the AudioTester software is the S/PDIF output of the ONYX with nothing between. AudioTester should generate the data rate set in the PC driver for the ONYX.
The feedback would be DCX A-out to ONYX A-in.
I hope I haven't misunderstood something. I'm not familiar with the ONYX.
regards,
Frank
Isn't there a possibility to connect your ONYX 400 via Firewire to the PC so that the output of the AudioTester software is the S/PDIF output of the ONYX with nothing between. AudioTester should generate the data rate set in the PC driver for the ONYX.
The feedback would be DCX A-out to ONYX A-in.
I hope I haven't misunderstood something. I'm not familiar with the ONYX.
regards,
Frank
The ONYX is connected to the computer via firewire (otherwise no measurement through AudioTester software would be possible) but
at least I didn't find a way to output the AudioTester signal to the SPDIF AES/EBU of the ONYX - only analog output seems to be possible which was not enough for comparing without changing anything in the setup but connecting cabels different.
Therefor I used a CD which basically gives the same performance (have a look at the close to perfect loop pic's).
No NEED, but any processing at higher rate/ bitrate gives better results in the end. Every sound studio processes their records at the highes possible rates and finaly downsamples to (inferior) CD standard.
Greetings
Michael
janneman said:
Hello Jan,
I am cerftanly no expert in this area but I do regard Guido Tent as Rolex for Audio when it comes to clocks and jitter. Instead of myself rewriting, here is the quote from Guido's site where he explains benefits of having clock XO2 within the CD player, and having XO - DAC within outboard DAC, link together with what he calls TentLink mode:
"Advantage
The advantage is that we now have a free running oscillator (XO) at the DAC side, with a resulting jitter of typically 3ps rms (3-sigma). The actual conversion within the DAC, which is most important, is now carried out with the lowest jitter possible.
The CD player drive is synchronised by the PLL in XO-DAC. The signal in-between (TENTlink) is low bandwidth, and sufficiently filtered at both sides, so a simple 2-wire interface can be used. This signal pulls the VCXO inside the player and as such synchronises with the DAC. Please note that the actual frequencies used in CD player and DAC do not change. This may imply that you have to change XO and VCXO frequencies. For that reason a no charge exchange service exists, you only pay shipping charges. "
And here is link for that page:
http://www.tentlabs.com/InfoSupport/Technology/page25/page25.html
I find his site very informative, and I really do respect his posts on the subject here on the DIY audio board. I do understand your argument of not having additional clock in the player, but also if my memory serves me well I beleive Wadia had a similar concept with outboard clock, and additional clock in player. I could be wrong on this one, not sure.
I would like to hear your opinion on Guido's product and concept.
Stay well
AR2
AR2 said:
Yes, I can relate to that. Having a free-running oscillator at the DAC side minimizes jitter there, where it is important: at the last clocking point. But, having it free run, there is the danger that it gets ahead or behind too much of the transport data clocking which could cause data under- or overrrun at the DAC. To avoid that you have to slave the transport to the DAC. But that transport slaving as such of course doesn't do anything to reduce jitter.
BTW I wonder whether that free running clock wouldn't cause things we thought we got rid of like good old wow and flutter?
Jan Didden
janneman said:
Good morning (for you) Jan,
Really good point. But isn't jitter result of deviation in phase timing, and maybe syncing drive and DAC minimise that timing deviation? I could be mixing idea of syncing and jitter reduction, but that is the same concept of world clock that I think not just sync all units in digital chain, but also lowers jitter by that very fact. I certainly could be mixing this two functions.
I like your coment regarding wow and flutter. Finaly we could have an argument that analog and digital are not that different.
for the people that like to argue about differerence between analog and digital.
AR2 said:
Well, if you picture a digital stream arriving at the DAC, and it is reclocked meaning that the level changes are set, time-wise, by that DAC/clock circuitry, I fail to see how the accuracy of the level changes in that stream before that can have any impact (assuming as said before, that they generally arrive on time so there is no under- or overrun).
Jan Didden