We are sending mclk to wm8805 , then we get the stream through the isolator (jittery) so we recloak using mclk (again) .
Yes we have a shield for clocks, we will see if needed.
No way to tap the mclk.
Back to testing..
We measure the MCLK...everything is reclocked with it. Flip flops add a minimum jitter so we are safe to assume that mclk jitter is spidif jitter
But what are you measuring with? What test equipment?
I'm curious because test gear that can accurately measure jitter in the 1.7ps range is quite expensive.
I think Ioan's just sticking an oscilloscope probe on the master clock, with a mega-buck Teledyne Lecroy:
Here's the Boss jitter: (0.6ps or 600 femtoseconds (standard deviation of the leading edge square wave)) -- audio things aside, just amazing the measurement equipment available today! Usually even the deferential probes are crazy expensive (but extreme precision and low noise) on their own!
Here's the Boss jitter: (0.6ps or 600 femtoseconds (standard deviation of the leading edge square wave)) -- audio things aside, just amazing the measurement equipment available today! Usually even the deferential probes are crazy expensive (but extreme precision and low noise) on their own!
Last edited:
I think Ioan's just sticking an oscilloscope probe on the master clock, with a mega-buck Teledyne Lecroy:
Here's the Boss jitter: (0.6ps or 600 femtoseconds (standard deviation of the leading edge square wave)) -- audio things aside, just amazing the measurement equipment available today! Usually even the deferential probes are crazy expensive (but extreme precision and low noise) on their own!
I work with SDI digital video interfaces daily. We are now able to transport 12gbs over coax. So I know a lot about high speed digital measurements. And of course where there's digital video, there is also digital audio at play in broadcast and mastering environments.
First of all, worrying about digital audio jitter in the picoseconds range is ridiculous. Based on the clock rates used in digital audio transmission, jitter at this level is insignificant.
Second as I said above, accurately measuring system jitter at these levels is complicated and expensive. Just because the master clock measures good at the oscillator pins does not mean the total systems jitter is anywhere near that good.
Just trying to keep the audiophile voodoo to a minimum here.
No Vodoo here..please bare my argument.
The spidif stream is coming to the flipfops (we actually use 2 flipflops for metastability),,,then the stream is sent once the mclk is present. Everything is sent out with mclk. So it stands to reason that mclk jitter is spidif jitter (flip flop aditional jitter is insignificant). However you are wrong thinking that ps jitter is inaudible. Aparently (multiple researches) show that ps range jitter is audible , but more important is phase noise. Phase noise up to 100Hz makes the 3d sound, rest adds to thd+n
I dont pretend to fully understand , just passing on what I know.
So yeah jitter will be in the 1ps range. Unfortunately I don't have the phase noise data.
But how are you forming the SPDIF stream? Simply passing the SPDIF stream through a flipflop or two may in fact APPEAR to make the jitter that of the Mclk. However any timing errors in the stream still remain. The only way to remove those timing errors is buffer memory.
Spifid is formed using the DATA and embedding clocks to it. So spidif stream is 2x data
However data is send as per bclk and as such it has a sample rate (22/24Mhz is an exact multiple)
So reclocking with a jitter free MCLK will in fact correct any jitters that are present in the spidif stream
We are seeing now 0.9ps jitter. The unit is fully working last tests this weeeknd.
However data is send as per bclk and as such it has a sample rate (22/24Mhz is an exact multiple)
So reclocking with a jitter free MCLK will in fact correct any jitters that are present in the spidif stream
We are seeing now 0.9ps jitter. The unit is fully working last tests this weeeknd.
But that still doesn't correct for timing mis-registration. All you are doing is making an arbitrary new transition, which in it's self is very low jitter but that's not the same place in time as the original transition.
We learned this in early serial digital video implementations. Simply re-clocking in many cases made the problem much worse. Now with the rather loose tolerances of digital audio, you will get away with it. But I just don't see the point of this re-clocking. Getting an oscillator to make sub nanosecond jitter specs is quite easy. Getting the entire circuit to make that spec is not so easy. If measuring the jitter from a re-clocked SPDIF stream, it will appear to be that of the oscillator - as you have shown. But the inherent timing errors are still in the signal. And that's what becomes audible when going through a DAC - that is if severe enough but again, digital audio jitter can be in the low microseconds and not be audible per professional standards. Note that is not audiophile standards which IMO, are arrived at with less than scientific approaches.
Imagine this...an analog singal is changed to a digital one at , lets say 44Khz and 16 bit.
You see, the master clock is an exact multiple of the 44Khz x 16 x 2 (L/R)
Not you have DATA coming out (on mclk/bclk)...if you realign that with the same exact multiple MCLK...in fact you realigned the original 44Khz with the jitter of MCLK...basicaly analog will come out in the best representation possible (compared with original sound translated to digital)
Do you agree ?
You see, the master clock is an exact multiple of the 44Khz x 16 x 2 (L/R)
Not you have DATA coming out (on mclk/bclk)...if you realign that with the same exact multiple MCLK...in fact you realigned the original 44Khz with the jitter of MCLK...basicaly analog will come out in the best representation possible (compared with original sound translated to digital)
Do you agree ?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.