clock jitter

Discussion in 'Converters / Interfaces' started by audiokid, Apr 18, 2010.

  • AT5047

    The New AT5047 Premier Studio Microphone Purity Transformed

  1. I've just been sitting back and assimilating it all. It's a good read.
     
  2. Boswell

    Boswell Moderator Distinguished Member

    Joined:
    Apr 19, 2006
    Location:
    UK
    Home Page:
    Yes, it's fine, and it's unlikely that people would want to take issue with what you have said.

    The relationship between jitter and uncertainty of sampling instant used to be clear cut in the early digital audio days of non-oversampled converters. These days, the actual clock into the A-D or D-A converter is of several MHz, phase-locked to the sampling clock. The phase-locking process can smooth out jitter in the sampling clock, but at the same time brings its own jitter problems, so without examining in detail the design of a particular piece of gear, it's difficult to say what is actually the dominant factor in the jitter specifications.
     
  3. audiokid

    audiokid Chris Staff

    Joined:
    Mar 20, 2000
    Location:
    BC, Canada
    Home Page:
    Yes, please continue. You are providing material that will be indexed and added to our Wiki. This is excellent and very appreciated!
     
  4. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    Thanks all for the response. I will continue asap but I'm a bit pushed for time over the next few days!



    I can't agree more. This is part of why I find that the way jitter is currently specified to be next to useless. View it as my personal crusade to produce meaningful spec's!
     
  5. soapfloats

    soapfloats Well-Known Member

    Joined:
    Aug 28, 2008
    Location:
    Cincinnati, OH
    Home Page:
    Keep it going in your own time.
    Most of my contemporaries on this thread are a great deal more well-versed than myself, but I know we all share a commitment to a better understanding of every aspect of our business. Regardless of perceived relevance, we should all at least be aware of such things and be able to discuss them.
    Thanks for putting in the effort.
     
  6. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    Well, so far I have tried to cover aspects of jitter related mainly to using a single soundcard and why I regard the way jitter is currently specified to be almost useless.

    If that raises any questions please let me know and I'll try to tackle them.

    In general, with a simple set up, with a single soundcard, jitter should never really be a problem and if it was I could only recommend ditching the particular soundcard.

    Things get more complex when slaving several soundcards together, or even using a set up such as soapfloats who uses a single soundcard with two input expanders synchronised via ADAT (or SPDIF or Wordclock!). For this scenario, soundcards generally (but not always), provide the facility to lock the internal clock to an external source. This could arrive from one of several sources as I have already mentioned in several different formats, namely SPDIF, ADAT, wordclock or, occasionally, a proprietry link between soundcards from the same manufacturer.

    In this case, the soundcards master oscillator that I have already discussed, requires some method of varying its frequency to enable it to be locked to the external source. To achieve this lock several things have to happen.

    First, the source clock data needs to be processed to extract the word timing (if not already a wordclock input). Both SPDIF and ADAT contain a lot more information (E.g. Audio data!) than the basic data rate but for synchronising clocks the data rate is all we want or need. Once we have what is effectively the wordclock for the source then the clock must be evaluated to determine its sample frequency, be it 44.1kHz, 96kHz etc. Once this is done, the master oscillator dividers can be set up to match the incoming data. Naturally whatever the sampling rate, the wordclock runs at a much lower frequency than the master oscillator so we must now have a circuit that locks the slaved master oscillator to the incoming source. This is called a phase locked loop (PLL) and there are many, many ways in which this can be implemented.

    While these circuits are in essence quite straightforward, I have come across many designs over many years that fall well short of the desired performance. In one notable case, a client thought performance was OK (contrary to their customers) - simply because they tested the circuit the same way as soundcard manufacturers. In this case not only had I to point out the error of the test method but also ended up completely redesigning their PLL as it was clear it was hopelessly inadequate nor did they grasp many the basics of PLL design. Unfortunately I have come across this many times over the years - don't get me wrong though, it's good business for me!

    Now if we take these more complex set ups where one or more devices are slaved to a master clock the whole situation becomes more variable. As Boswell pointed out, without knowing the specific circuits we can't easily surmise where problems might arise or what the "real" timing errors of these systems might be.

    More later...
     
  7. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    Well it is now much later than I expected!

    So hopefully I have now explained reasonably clearly how we lock one clock to another. The only note to make is that we now have a master oscillator that can be shifted in frequency but when used on internal reference, the soundcard will use a fixed voltage to set the reference frequency. The addition of this control system inevitably contributes additional phase noise but unless the designer has been very careless, the extra noise should be insignificant.

    So what happens when we lock one reference to another and use both soundcards for recording. Well first of all, with the spec's I gave previously:-

    Jitter <20ps RMS, 20Hz-20kHz
    Jitter Attenuation >60dB, 1ns in=>1ps out

    Given that spec you might reasonably expect that given two soundcards with these specifications that the maximum variation in sampling time would perhaps be <20ps + 1ps or even 20 +20 ps (as I did mention earlier that 1ps will never happen if the unslaved spec is 20ps).

    Not even close I'm afraid! This, again, is precisely why I hold that the way jitter spec's are currently presented are next to useless. Not only that but without considerably more information we cannot even hope to calculate the real situation.

    What we certainly cannot expect is that when a certain cycle has a minimum period (i.e. clock period - 20ps) that the next cycle will somehow magically balance the error with a period with an extra 20ps. In fact it is normally very much the opposite. In addition, while the example spec. I have used states RMS, 20Hz - 20kHz, it is a fact that the noise will, as a result of being essentially guassian noise, have more significant components nearer to DC. There simply is no relation to the "audio" bandwidth suggested by the spec. that makes the sub 20Hz performance irrelevant. This lower frequency noise (jitter) cannot be ignored when evaluating the overall timing of a clock and this is considerably compounded when two clocks are slaved together. While the jitter in this bandwidth can certainly be measured, to present the spec in this way is simply masking the truth.


    I was intending to write more in this session but have run out of time. I'll be back later.
     
  8. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    Just a very quick note. As a picture paints a thousand words, I am hoping to produce some piccies of some of this but it will take some time to sort out. I'll carry on with words in the meantime.
     
  9. soapfloats

    soapfloats Well-Known Member

    Joined:
    Aug 28, 2008
    Location:
    Cincinnati, OH
    Home Page:
    On a side note, and also related to my issue:
    All of the literature from Presonus suggests that the device doing the most work (in my case, the Firestudio) should be the master.
    The ADAT devices should be set to slave. Now, in my case, at least one of these devices has issues doing that.

    Assuming they all play nice, is the above the truth?
    I only ask b/c you refer to having the main clock or oscillator lock to external devices.
    Is there a preferred master-slave relationship?
    Or is it a matter of (esp. in my case) go w/ what has the most stability?
    And does this relationship have an effect on jitter?

    If the answer adds to the discussion, please provide it.
    If not, continue on.
     
  10. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    First of all I had not realised I had implied that the master clock should be slaved to another. I'm not sure where that is, so I'll have to read back! The key here is that the master clock is defined as being the source clock with other devices slaved to it. If you change which device provides the source clock, you have effectively changed the master.

    In your case then certainly the Firestudio should be the master. With your set up, using one of the DIGI's as master and slaving the Firestudio to that would be an option but you should also slave the second DIGI to the first DIGI either via wordclock or SPDIF. If you slave the second DIGI to the FireStudio, while it should work, you have no overall master and jitter will accumulate. As one of the DIGI's appears to have a fault and will not lock reliably to an external source you may have no option but to use this one as master. If we assume that the clock circuits in both the DIGI's and Firestudio are the same (not a safe assumption by any means) then this should not degrade the overall performance. That is the rub, there is no way of telling from the spec's which configuration would give the best performance. As one of your DIGI's is dodgy (!) and presumably not warranted, it may be worth giving the insides a close inspection for dry joints etc. as it seems to be intermittent.

    I intend covering more on master/slave set ups later.
     
  11. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    Just another quick thought for soapfloats. It could be that the reason the faulty DIGI will not lock reliably is due to a fault in the oscillator (among many other things of course). It is therefore possible that using this DIGI as the master clock could also mean overall increased jitter. The only way to tell for sure is to get the faulty DIGI tested and preferably fixed.
     
  12. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    I've managed to find a bit of time to get some basic photo's together!

    Rather than just spout on about how jitter arises and what the spec's mean I think these photo's will show what happens a bit more clearly. What I've done is to use my Yamaha 01V (original) together with my original MOTU828.

    These are linked together via ADAT lightpipe and I've used both devices as the clock source to measure the relative jitter on the S/PDIF outputs. In both devices the cycle to cycle jitter is in the order of a few tens of picoseconds (as are, I expect, just about all soundcards that are slaved or not). I've never bothered to do this before and the exercise has proved what I expected but also thrown up one small oddity I did not anticipate.

    OK, the first photo is of the 01V slaved to the MOTU on a coarse scale to see the timing variations. I'm afraid my "best" scope is currently dead so I have used an older digital scope which is quite adequate to show the problems and also allows me to display the full range of the timing variations over a period of time.

    MOTURef_out.jpg

    The lower trace is the 01V S/PDIF output and the upper is the MOTU output in all cases. Horizontal scale is 50ns per division. The first thing to notice is that the 01V output is delayed by approximately 250ns relative to the MOTU. This is a systematic error and although a perfect system would show the signals in perfect sync., in practise a fixed delay of 250ns is not large enough to cause any phasing issues. Bear in mind that the period of 20kHz is 50us so 250ns equates to 1.8 degrees of error - absolutely insignificant compared to moving a mic a fraction of an inch! What you can also see is quite a timing variation on the upper trace. Bear in mind I am always triggering the scope from the 01V signal so that variation is effectively the jitter on the 01V output relative to the MOTU output. This is shown more accurately later but note that the relative jitter is around 20ns or so. Forget cycle to cycle jitter, this measurement is what is REALLY important as this shows that timing of when you will actually get your samples.

    Photo 2 is the same set up but with the MOTU slaved to the 01V.

    01VRef_out.jpg

    Here we see that the jitter is similar but this time the MOTU output is delayed realtive to the 01V but this time by the smaller amount of 200ns. Again, for our purposes this is not really relevant. The amount of jitter is similar to the first photo. What I cannot easily show you here is the "nature" of the jitter, so I'll just have to try and explain the differences I noted. The jitter caused when the 01V is slave is apparently relatively wideband and appears to be essentially guassian noise. Without resorting to my spectrum analysers (and I'm NOT lugging them from my lab to the studio) I don't know what the full bandwidth of the noise is so this is just my judgement. With the MOTU as slave, as we can see, the magnitude of the jitter is about the same but the character is quite different and is predominantly low frequency (you can actually see it bouncing around as the scope picture builds). These different characteristics will alter how the sampled signal becomes modulated by the jitter.

    The third picture is the same as #1 but zoomed in to see the jitter more precisely showing the peak to peak jitter of around 26ns

    MOTURef_in.jpg

    #4 is as #2 showing about 23ns jitter.

    01VRef_in.jpg

    While I was doing these tests, I was storing the results over about 45 seconds or so which seems adequate to catch all the variations however I did get diverted and noticed the MOTU, when slaved, occasionally has a "blip" which causes a significant increase in the jitter. This is shown in the last photo, #5.

    01VRef_prob.jpg

    This happens infrequently (every few minutes or so) and I can only ascribe this to some systematic fault in the logic of the system. It certainly does not appear to be a character of the phase locked loop circuit.

    The most important thing to take from these photo's is that the real world jitter is actually in the order of tens of nanoseconds rather than the tens of picoseconds that it seems the manufacturers specifications would have us believe and also there is simply not enough information in the "cycle to cycle" measurements for us to calculate the real world jitter figures that I have given here.

    Next will be a few simple calculations to show roughly what all this means to our recordings!
     
  13. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    Just to let you know that I won't be around for a week or two. I am taking a laptop away with me but will not have regular internet access. I will be trying to write up some more "chunks" ready for posting, time permitting, whilst away.
     
  14. soapfloats

    soapfloats Well-Known Member

    Joined:
    Aug 28, 2008
    Location:
    Cincinnati, OH
    Home Page:
    Keep it up, your photos of your tests were very helpful!
     
  15. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    PLEASE NOTE (AS KINDLY POINTED OUT BY BOSWELL) THAT I HAVE MADE A CARELESS SLIP IN MY MATHS IN THIS POST AND THE RESULTS I GIVE ARE FAR TOO OPTIMISTIC! PLEASE READ FURTHER POSTS IF YOU ARE INTERESTED.



    Sorry but it's been some time since I could add to this thread, so I'll just get on with it for now!


    Now I have shown some fairly typical, measured, results in measuring the true timing jitter of slaved clocks, we need to see what kind of effect it will have on our audio fidelity. I will first make a couple of assumptions.

    1. The highest frequency of interest to us is 20 kHz.
    2. The maximum level of the converters is 2 V p-p (peak to peak) before clipping.

    These are straightforward assumptions however I'm sure some will contend the benefits of having audio bandwidth up to 40 kHz or more. If you are in this camp all you will need to do is adjust the appropriate figures I will give you.

    So if we have a sine wave at 20 kHz, 2V p-p then the maximum slew rate of the wave is (approx) 125 V/s. If we now take the measured results of the jitter as 25 ns (I like round figures!) then the maximum possible variation on a sample is 3.125 uV. This is spread both sides of the ideal timing so the error is around +/- 1.55 uV. I will term this as the "maximum jitter modulation". This is 116 dB below 0dBFS and certainly, for my converters at least, is below the converter noise level.

    That is not quite the end of the story though as the perception of a signal at this level depends on what the signal is. If the jitter noise happened to be the result of a sine wave modulation, the signal created by the jitter would be a similar sine wave. Because coherent signals can easily be perceived below noise then such jitter might be noticed, particularly in quiet passages (sadly not likely with a modern compressed CD).

    This is why the nature of the jitter is important. In the two examples I gave, my 01V gave what appeared to be pretty random phase noise (note that I could not directly measure this with the set up I had) and therefore the jitter modulation is non coherent and therefore much less likely to be perceived. In the other instance, the MOTU 828 had what appeared to be predominantly very low frequency jitter and such modulation would result in signals outside the audio bandwidth. Relate this to the specification I gave much earlier, in reference to Soapfloats querie's, where the jitter bandwidth was given as part of the spec. Although that particular spec. tells us very little of what the actual jitter is, it does tell us that the jitter should not cause significant jitter modulation within the audio bandwidth.

    I hope this gives some idea what the real magnitude of the problems arising from clock jitter really are. I hope that this description has been both useful and understandable and that will now have an appreciation of what clock jitter means in the "real" world. In essence, unless you have very poor clock circuits, it is very unlikely to impair your recordings. Of course it would be nice to have things perfect but it is also good to appreciate the engineering compromises we designers always have to make.



    For those interested this last bit explains a little bit more of the maths and the reasons for the assumptions I've made in the calculations. Please skip it if you're not bothered by it.

    A sine wave is described mathematically by Vout= A*sin(wt) (using w to represent omega), where the magnitude of the wave is set by A. In this case A=1 gives a sine wave of 2Vp-p. To find the maximum slew rate, we differentiate this expression with respect to time to give dV/dt (the rate of change of voltage) = w cos(wt), this is a maximum when cos(wt) = 1, hence dV/dt(max) = w. w = 2*pi*frequency = 125.663 V/s.

    While I fully appreciate many musical instruments can produce much faster transients than this, the only implication is that frequencies above 20 kHz are present, hence this is a sensible assumption. I appreciate that many electronic circuits can also create high order distortions within the audio band as a result of these higher frequencies. The fact is that even with a 20 kHz square wave, if we could put that through a perfect "brick wall" 20 kHz LP filter, then there would be no dV/dt exceeding this figure. Indeed many high quality power amplifiers use a (simple) LP filter on their input stage in order to prevent fast transients causing any of the high order problems normally more prevalent in power stages.

    If you prefer to take 40 kHz as a yardstick (although I have never personally seen a compelling reason to do so) then the only effect is to increase the jitter modulation noise by 6dB from the figure I calculated above, i.e. 110dB below 0dBFS.

    While you may consider this to be a significant degredation to the highest performance converters it is also important to compare like with like. Converters boasting up to 120dB of dynamic range are available but bear in mind that these will be "weighted" figures, whereas the calculations I have given here are not. I could only weight them if I knew the spectral density of the jitter noise. It is also highly unlikely that you will have a recording facility with a low enough ambient noise to ever achieve such dynamic range figures in any case.
     
  16. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    What I should also point out (as I have not made it clear) is that the figures I have given are absolute worst case. It is not possible for the 125 V/s slew rate to exist more than instantaneously and this will only occur with a signal of 0dBFS at 20 kHz. Real audio waveforms will be very unusual (effectively impossible) if they contained anything remotely near this level. The net result is that normal audio data will have a very much reduced jitter modulation noise from the figures I gave. This all tends to suggest, to my engineering side, that jitter noise will very very rarely be the cause of any problems.

    I hope that I have not only explained what jitter clock jitter is, as originally asked, but also shown what effect it will have and finally, that for all intents and purposes, it would never, under any normal circumstances, cause us any real problem.

    Of course if you find any part of this explanation unclear or incorrect I would welcome your comments in this thread. I will then try to explain further or correct any errors. Equally if you find you agree with this explanation, please chime in as that could also add weight to what has been a purely solo effort!
     
  17. audiokid

    audiokid Chris Staff

    Joined:
    Mar 20, 2000
    Location:
    BC, Canada
    Home Page:
    Wow, I need to read and think and read and think. Thank you so much.
     
  18. djmukilteo

    djmukilteo Well-Known Member

    Joined:
    Nov 23, 2008
    Location:
    Rainy Roads WA USA
    Good technical stuff....always exciting and interesting to me when I can read some tech talk!
    I've been following another forum thread where the ongoing discussion is external clocks. The discussion for the most part is high end clocks....
    I guess I won't mention any names but the debate is 10Mhz atomic master clocks creating better perceived audio.
    The science on the one side makes claim that a properly designed internal clock and jitter suppression circuitry within a well designed converter is a better clock than using one of these 10M external master clock units. The other side claims that highly renowned, experienced producers and engineers have no problem discerning a noticeable difference in the quality of the audio being converted and monitored from their A/D/A's when using said high end clocks.....
    While I lean toward the science and engineering side of this and not having any expert listening experience (I think I have good ears LOL)...or even really high end equipment at my disposal ($6000 for an atomic clock is a little out of my price range!)...do you think there is something going on here that has a reasonable explanation? Or is this high end clock thing hyped and is there possibly "listening bias" going on here with experienced people hearing a perceived improvement?
    In my mind and understanding with A/D/A reaching 120db of dynamic range and possible sideband artifacts down in the -110 range....is it really possible that these extremely accurate timing circuits could produce a perceived improvement in the audio and where (if at all) could this be shown or proven?
    So thanks MrEase, Boswell and Scott for your contributions to this thread!
    I'm reading it.....
    And FWIW RO is far more professional, open and truly free from the incredibly augmentative nonsense that goes on over there!
    Thank you for that audiokid!
     
  19. Boswell

    Boswell Moderator Distinguished Member

    Joined:
    Apr 19, 2006
    Location:
    UK
    Home Page:
    Great analysis, but I think you dropped the K in KHz, making the figures 60dB worse than you suggested!

    At 20KHz, the angular frequency is 125664 rad/sec, so the max gradient of a 1Vpk sinewave is 125.664V/ms or 0.125664 V/us. Your (huge) 25ns jitter translates to a 3.14159mV (pi) uncertainty pk-pk. This is -56dBFS, which would be very audible.
     
  20. MrEase

    MrEase Active Member

    Joined:
    Jan 19, 2006
    Location:
    West Suss ex, UK
    Big thanks to Boswell for pointing out the slip! I can only say "woops", this type of thing always happens when you try to fit these things in with the time available. I actually have the slip of paper in front of me where I have written down 125.663 V/s instead of 125.663 V/ms! I must admit that the consequent results took me by surprise and I thought had got me out of going in as deep as I originally anticipated!

    Of course Boswell is correct and this is more the result I had been expecting (never having bothered to calculate this before) and which my earlier posts had been "teeing up" so to speak.

    So the explanation continues with what I had originally anticipated saying.

    Unfortunately I can't do this immediately but I will be back soon....

    Thanks again Boswell!
     
  • AT5047

    The New AT5047 Premier Studio Microphone Purity Transformed

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice