Jitter - Musings and Measurements
Example of signal with and without jitter
Jitter is one of common topics of conversation in Hi-Fi audio circles. Lots of people are eager to offer their opinions, but it appears that few really know what they're talking about. Some even argue that it's just another flavour of those audio snake oils. Others make it sound like solving a jitter problem will cause a new sun to rise over the wasteland of high end audio. From personal point of view, I don't feel like I'm a know-it-all on the subject of jitter (not just feel, I know I don't know a fair bit) but that attitude will get me nowhere - the current society seems to strongly favour people with a know-it-all attitude, with only a modest regard to their actual knowledge, and given the amount of knowledge I do have on the subject and the amount that seems to be necessary in order to claim "expertise" on any subject, I'm going to act as one (an expert know it all, that is) for the duration of this rant.
And make no mistake, it's a rant. Because I am pissed off. Not that it is very hard to piss me off. Anyway, about jitter, that is an engineering issue, and I am an engineer, in the old-fashioned sense of the word - I went through a five-year degree while nowdays a lot of people with an accelerated one-year degree are being called engineers. Not that there's anything wrong with those degrees, but they're mostly focused on ephemeral knowledge that is in demand at the moment. This is because the capitalist economy's way of dealing with shortage of people and inability to train sufficient numbers of new ones due to very high mental demands (meaning there aren't enough people in the world with the right abilities to create so many engineers) was to instead lower the criteria, lower the bar and let many more people get through. In one way that is understandable because when you go to the industry you'll see that vast majority of those jobs require only modest knowledge and talent - and actually that wasn't the case before either, that is the other way the economy adapted - by making jobs less demanding by way of automating, standardizing, moving to customization instead of from-scratch development and so on. Which is all good for the industry - leads to lower cost and creates a much bigger labour pool. Not so good - to put it mildly - for the old guard of engineers: low salaries, lots of competition for jobs, and the jobs themselves have become boring and repetitive. But all that is the result of economy and it isn't much worth bitching about (you can't change it, the only thing you can do is move out to another job where you can take advantage of your education and experience to appear more valuable). One side effect however is worth complaining about though - the devaluation of the title "engineer". Once commanding respect on the similar level as a doctor, now it's a title that could even apply to a person working in a low-pay job, roughly equivalent to a retail clerk position when hourly rates are considered. Meaning, it doesn't carry much value. Imagine how happy would doctors be if they allowed all other medical practictioners, like chiropractors, aromatherapist, masseuers, physiotherapists, home care workers and so on to be called doctors. Again to emphasize, those are all good and worthy professions, the only issue here is comparing 6-8 years of extensive and broad education and experience that a doctor in training goes through and 1-3 years college with a more narrow focus. Calling every practitioner a "doctor" would not happen easily thanks to very powerful doctor's associations and the fairly heavy influence of government in most countries on the industry (if you want to call it industry). There is no such thing in most western countries when it comes to engineers (there is a "professional" engineer title but it doesn't seem to carry much weight any more). Once you let the market determine value of the "engineer" title, you'll find it will make sure to make it as small as possible because, again, it allows for easy and cheap filling of job vacancies. So we're victims of our own popularity. That's not the worst part though.
The worst part is that the lesser (and one more time, lesser in the amount of education and the actual cost in dollars to the person and the society, not necessarily less in value to the society, that would depend on how the person uses that knowledge) degrees, that are great for getting a job, however long it lasts (doesn't depend much on the length of the degree anyway), sometimes lead to arrogance. I'd guess that is due to cases where a person might've been hired straight from the college and ended up with better pay than the guy with the "full" degree, therefore making it look like the other person laboured several extra years of their life only to end up worse. But that is only the case if you view the world with the narrow view through the high-diopter lenses of Buck & Ladder Co. (mighty buck and corporate ladder is what that meant). Perhaps it matters not to them that the other person knows of inner workings of the machinery they only know the high level block diagrams of, for example. All fine, until they start thinking that they actually know more than the other guy since, hey, obviously I got the job and the money, and the other guy wasted two or three years extra and now I'm HIS boss, how stupid he must be, and obviously corporation thinks that too since I am the boss, and corporation is mother and is a father, and mom knows best, hence I'm really so much better than him (her). Let me put it this way for those kinds of people then, do you actually think that your job would've existed were it not for the people like the other guy having to create something first? That big metal box you got educated about and got hired to work on on wouldn't ever get designed and built. Because it's they who know how it works - all you really know is what all the knobs on it are for. So if one of them tells you that thee's a process called "jitter" inside that box is influencing its behaviour and causing trouble, you shouldn't dismiss it just because you don't see a knob that says "jitter" anywhere on it (or rather, your professor never told you about one). In fact, go to whatever temple you pray in and thank God for jitter (or whatever else) for enabling you to have that nice job where you boss people around and fiddle with knobs. And if you're bossing around, remember, job of a manager is to delegate and to facilitate the solution, not to actually solve the problem. If you were supposed to know how it works, then why'd the other guy ever got hired?
Honestly the worst thing you can do to yourself is to not know what is it that you don't know. Major goal of a university degree is to teach you how to teach yourself, that's what I've been told by a professor. I'd add that you're going to forget most of what you learned, so learning how and where to find the information once you start working is a key. But this begs the question, why are you being so throughly and persistently tested through it all? No one told me that, but I'd say it is so that you can prove that given the knowledge you WILL be able to solve the problem, eventually. So, you will forget a lot, but if you know how to get the information back when you need it, you will be able to use it to solve the problem, because you proved it over and over and over again in the exercises and tests, earning quite literary your degree. Anyway, if you were taught about mathematics and physics first, so that you can understand Schroedinger's equations (wave function, whatever it was), so you know how semicondutors work, then about the electrical network equations ( coming from Maxwell's equations) and leading to electronic circuit understanding, amplifiers, oscillators and such, before being taught a programming language, or any telecommunications subject such as networking protocols or multiplexes or whatever, then you're in it obviously for a different reason than a person who just went in straight on a diet of programming languages, patterns, configuration of routers and application servers or SQL query optimizations. You can expect to have an easier time getting a job and, fair enough, because that is all that vast majority of employers need. You are most likely not even going to be in much, if any disadvantage because you don't know how it really works; when the config screen pops up, you understand what each of the parameters does, but do you REALLY know why 128-bit is more secure than 48, or how CRC really works or how does JPG or MP3 really work? You could've even been explained all of those in a nutshell - which is usually where the root of the problem is. Do you know where the limits of your knowledge lies? You don't expect to get paid unless you work so you shouldn't expect to know what you haven't learned, or expect to know more than someone who invested larger chunk of their lives than you. It's not a matter of superiority, it's a matter of investment - of time and effort. If you invest in your RRSP (401K in US) through your working life you expect higher pension than if you only invest through the second half of it, right? That doesn't mean the other person "wasted" the money in the first half either, they simply have invested it in something else for a different kind of payout - maybe they got a house earlier than you or spent money on partying and ended up with a prettier wife than you did, or went on great vacations every year, and so on.
It works both ways of course - if I have an advanced question about networking then I will ask a friend who administers big networks for a living to help me out instead of relying on my knowledge from an advanced networking course for a master's degree I took (completed the course, not the degree) because frankly it was very dry and all I remember is that we analyzed performance of a network by simulating a flow of packets using realistic data (me and my lab partner captured packet data from the game Unreal Tournament no less). That doesn't help me at all when I am comfronted by an arcane text file that I need to write in order to set up masquerading and forwarding on a Linux box because, say, I need to have one machine on two different networks.
Did I veer of the subject? Rather sort of fell off the cliff, you say? Well jeez Louise, this IS a rant, what DID you expect??
So then, what is jitter? It certainly isn't snake oil, because if it was dismissed as such by engineers, you wouldn't have a working digital communications network such as the one you're using right now to read this. You wouldn't be able to talk on the modern telephone today (with digital communication between CO's (CO = central office) if engineers who designed the equipment ignored the existence of jitter. You'll see why a bit later on. There are courses at universities that make jitter a large part of their curriculum. ITU standards (defining pretty much the whole telecommunication area) have provisions for jitter in specifications for digital multiplexes. And probably much more than I would know of, since I haven't been in the field since early 90's. Ignoring jitter would be like ignoring the grease in a gear. In a high-level abstract view, such as an executive block diagram or a textbook, you don't need to think about it. In real world however metal isn't perfect, it doesn't have a perfect slick surface with no traction, and it definitely does wear out. So you need to consider that when you're designing and building one.
But what is jitter? It is a phenomena where the period of a signal, which is supposed to be constant, varies in time. For example, if the period of signal is T, and current time is t and we have a leading edge, then the next leading edge should come at t+T. But in reality it will come at t+T+dt. dt (which can be positive or negative) is typically very small compared to T, but it isn't a constant, rather it changes in time itself. You could liken this to having a pencil drawing (such as uncoloured comic) and you make several copies on a transparency, and then overlay those transparencies but don't align them perfectly, rather have them slightly off centre randomly for each image. What you would get is a blurred composite image, where you could make out the main features of the original drawing and where they are but not with any great precision.
Now, any properly designed digital equipment is capable of handling a certain amount of jitter that it will encounter in its normal operation. Unless there is a comparison of frequencies happening somewhere, the equipment may even be able to tolerate any amount of jitter, making it a non-issue, from the functional perspective at least. Whenever the signal comes it will get processed and passed to the output - still containing the jitter. But say you had a task to design a multiplexer that is supposed to combine several different data feeds into one composite data stream. For example, say you want to combine data from 32 telephones (after A/D conversion), and multiplex them together to send them over a single wire from the central office to wherever it's supposed to go next. There's 32 wires coming into central office but obviously you want only a few between different central offices so that is why you need to multiplex. To make things simple, say that we'll do it by taking one bit from the first line, then one bit from the second line, and so on until we reach the final 32nd line, and then we go back to the first line for the next bit, and so on. In reality there'd be some extra data but let's say that this is all. Now, how are you going to sample all those signals? They are digital but you have a very small window of time within which you have to decide if the line is 0 or 1. That's dead simple if your signals are based on the same clock, but in this case they are not (well, actually they could be for this particular example but in many cases you are combining input from fully independent devices, each with their own clock)? In reality their frequencies are not going to be identical though they will be very close. Worse yet, the frequency itself will vary in time due to jitter. As such you can imagine that over time the difference will accumulate enough to skip a bit, or to read it twice, depending on whether the other signal is faster or slower. So you will need an engineering solution in order to make sure you don't get such errors in the final result. Incidentally, this is similar to the way you'd implement full reclocking in a DAC, which very few products do.
What's causing jitter? Usually, the combination of several things, like noise (thermal, interference), mismatched impedances (or cable imperfections causing non-uniform impedance along the cable), nonlinear analog processing (distortion in transmitting and receiving amplifiers and in all components in general).
But why does the jitter matter for audio? Well, let's start from the beginning. You will have a certain amount of jitter on the input signal coming over toslink or coax. Next comes the receiver chip which runs its own clock (with its own jitter by the way), and uses a PLL to extract the clock of the data signal. Integral part of PLL operation is a filter, and this filter can actually attenuate the jitter - and it does, to a certain point. Now, the receiver is an example of a device that does need to be fed signal that has jitter below certain point otherwise it will be incapable of working. This is because it runs its own clock and there will be comparison of the two, extreme jitter could make one frequency appear considerably different from the other, and the PLL typically has a "pull" range - if the frequencies are far enough apart, it won't be able to "lock". Without lock there is no clock extraction and the receiver will just not work at all. This is typical of digital equipment - it will tolerate a wide range of out-of-spec signals, but once a boundary is crossed it just goes from working near-perfectly to not working at all. While analog goes from good to not so good to bad to worse to terrible. Basically quality of the signal matters very much in analog while it doesn't matter much in digital as long as it's within tolerances. That is why digital took over analog many decades ago by the way - you can still get a perfect reproduction on the other end even if there was considerable noise in the transmission line.
Now this "recovered" clock and data are being fed into the DAC chip. There will be some jitter present there, but it will be attenuated compared to the input (usually, not always the case). DAC is a device that might be fairly insensitive to jitter as far as its functionality is concerned - it will make a sound on its output regardless of jitter and it will generally sound as it is supposed to. It will not be a discrete event like the receiver chip where it either works or it doesn't - it will work but the degradation of the output signal will occur. This degradation is not readily heard - as in there are no pops, hisses or gross distortions - if it were, this whole treatise would be unnecessary. However, one thing is certain: jitter WILL make a difference in the D/A process.
And this is where most of the flame wars occur. People claim that it can't possibly make any difference because it's all ones and zeroes and if those are accurate, then it's going to be a perfect reproduction. It's digital after all, isn't it?
Well, that comes from the typical watering down of facts that are presented in many schools these days in order to simplify the education. Thinking that you know everything there is to know, but not realizing that your knowledge will work only in a perfect world. Also the word "digital" is used for way too many different things these days. Digital in mathematics is nice and clean and easy. Digital in physics is nice, clean and easy - only when idealized and abstracted. What happens is that we take stuff from the world of physics and "encode" it into the world of mathematics. Once there, perfect and clean operaations are possible (not always but let's not digress) and you can always guarantee your data's integrity. Until you need to pass it back to the real world of physics in order to get any use out of it, until you "decode" it. To a picture, a sound, a printed text, a graph on screen, whatever. What you may be ignoring is that both your decoding and encoding from one world to another may be far more complex than you know and that there is a loss of information occuring in both encoding and decoding. Even stuff that only stores and transmits data without doing any interpretation or rendering - say, transmission or storage of digital data - is not as simple as it looks. It can be bit-perfect, despite of noise and jitter, thanks to digital paradigm, and if that is not enough, error correction algorithms and so on. But even just transfering some bits is a complex matter that only works because so many things are taken into account (shielding conductors, terminating the characteristic impedance, using autocorrelation, filtering and so on, each of which is a complex consideration in science). Let alone storing the information. So thinking that rendering the information in the end is going to be perfect just because we had perfect 1's and 0's is like believing that you can cook just as well as your mom just because she gave you her recipe and you can read.
Digital, eh? What an abused word, and how often misunderstood! The worst "offenders" are people who went through one of those educational systems that have you memorize a few formulas or a few commandments, instead of explaining the whole thing from basics. Thinking that you know everything there is to know, but not realizing that your knowledge will work only in a perfect world. Also the word "digital" is used for way too many different things these days. Digital in mathematics is nice and clean and easy. Digital in physics is nice, clean and easy - only when idealized and abstracted. What happens is that we take stuff from the world of physics and "encode" it into the world of mathematics. Once there, perfect and clean operaations are possible (not always but let's not digress) and you can always guarantee your data's integrity. Until you need to pass it back to the real world of physics in order to get any use out of it, until you "decode" it. To a picture, a sound, a printed text, a graph on screen, whatever. What you may be ignoring is that both your decoding and encoding from one world to another may be far more complex than you know and that there is a loss of information occuring in both encoding and decoding. Even stuff that only stores and transmits data without doing any interpretation or rendering - say, transmission or storage of digital data - is not as simple as it looks. It can be bit-perfect, despite of noise and jitter, thanks to digital paradigm, and if that is not enough, error correction algorithms and so on. But even just transfering some bits is a complex matter that only works because so many things are taken into account (shielding conductors, terminating the characteristic impedance, using autocorrelation, filtering and so on, each of which is a complex consideration in science). Let alone storing the information. So thinking that rendering the information in the end is going to be perfect just because we had perfect 1's and 0's is like believing that you can cook just as well as your mom just because she gave you her recipe and you can read.
Anyway, unless you know what Fourier transform is, and how the formula looks like and how it was derived in the first place, you have no business discussing the effect of jitter on D/A conversion. If you've seen the equation, then you know that you have the sampling frequency as a very prominent part of it. The formula assumes that it's a constant, and if so, indeed only "ones and zeroes" (i.e. the sample values) matter. So is it a constant? Not with jitter it isn't!
There are articles that describe with a liberal dose of mathematics the effects of jitter. It's not hard to describe if you know a bit about trigonometric functions (sine and cosine and so on). You then know that if you add another factor to the argument of sine, that you can break down the expression into a sum of two sines. In other words, if your signal was a pure sine, and you added a simple sinusoidal jitter to it (i.e. the frequency of the sine varies in time as described by another sine function of different frequency), the end signal - that is, what you'd get after D/A - would be the original plus the side lobes, i.e. extra harmonics around the base signal, spaced by the frequency of the jitter. Now, the jitter isn't of pure sinusoidal form in practice, and in addition, different DAC architectures react differently to it, but the end result is - if you bother reading and understanding the math - is either increased noise floor (i.e. decrease in SNR) or extra harmonics, or both. And this can be measured as well. So much for snake oil, unless you want to deny existence of anacondas even as one is strangling you as you speak.
While theoretical analysis of jitter requires considerable math and engineering skills, and practical measurement requires very precise instruments that cost a lot of money, you can still get a taste of what it's like with just a (very good) soundcard. All you need is one with great A/D convertor. You would play a specially constructed signal - a very high level pure sine, at -3dB probably to prevent clipping distortion which can occasionally occur if you get too close to 0dB - at a quarter of sampling frequency, say 11025Hz, superimposed with the lowest level square wave that the signal resolution can carry - and that would be the least significant bit. This last one is set to a low frequency, say 229Hz. If you know about Fourier transform, you know that a square wave can be broken into an infinite series of harmonics, where only odd harmonics are present, and the envelope (i.e. the intensity of harmonics) drops off at an "exponential" rate. I can't remember if it's really exponential or more likely it's one of the Bessel functions, but at any rate the intensity drops fast enough that really only the first one or two dozen together can define the signal pretty well while the others fall below noise floor (in theory they go into infinity, but at the same time it's physically impossible to have an infinite slew rate which you'd need for a pure square wave, so it's all good). Anyhow, if you feed this signal into your device under test, and then capture its output using your soundcard, and a spectrum analyzer software, like free Spectrum Laboratory, then you'll be able to see a nice spectrum as described. Now, if you zoom to a few kHz aroun the 11025Hz peak, you may be able to see a few of those side lobes I mentioned before, i.e. the harmonics that are result of the data-induced jitter (jitter induced on the carrier, i.e. the sample rate signal by the data content of the signal). This method is used by Stereophile as well, though they have better spectrum analyzers (or rather, better A/D data acquisition hardware). You can see an example in this article, which is where I got the idea from. The guy who made those DACs holds a masters degree in EE, so he had no problem adapting the Dunn paper he mentions for his use. I got the file from his site.
Just to make sure this is understood, this is not all the jitter there is. I haven't analyzed this in great detail but I don't believe that this allows you to see or measure jitter of the clock signal itself, for example. You still need (expensive) equipment and (elaborate) process to measure it. I believe this only shows data induced jitter. But if all you're trying to show is that jitter DOES matter in audio, then this will serve the purpose well.
Now take a look at the differnce that a different digital receiver chip can make. These are identical DACs, down to the layout, except for the digital receiver chip (and perhaps a bit of power supplies to those receivers, which actually does matter). Here are the results for AK4117 and for DIR1703E. The first one claims "low jitter" just as any other, where "low" is around 180ps. DIR1703E claims much lower jitter, about 75ps. Interestingly enough, the jitter attenuation function of the PLL of both of those chips are very similar. So, how then do we get a drastic difference like this?
Figure 2 - AK4117 jitter
Figure 3 - DIR1703E jitter
If you use the formula in the link above, you can get the values that are fairly close to what manufacturers claim. Bear in mind that data-induced jitter isn't the only type of jitter! A good source of jitter are the clock oscillators themselves, and according to the article in Marc Heinlinger's DAC, jitter in those oscillators can be substantial at low frequencies. Indeed, at high frequencies it will get attenuated by PLL - but they only start working near the end of audible range, 10-20kHz, which means any jitter in audible range on the clock will not get attenuated. If you look at the jitter attenuation of asynchronous sample rate converters (take a look at AD1896 datasheet) you will see that they start attenuating even below audible range, at only a few Hz. So if clock oscillators indeed have a low frequency component in their jitter, then ASRC are a worthwhile consideration for improving sound quality to be sure.
Therefore, we most certainly have a scientific reason, one that can be described both theoretically and measured empirically, as to why jitter makes a difference to the end signal. Therefore it MAY BE POSSIBLE to hear a difference that jitter makes. I can't say whether it's audible, as double-blind tests and such would be necessary, and every time you involve humans in a subjective way you run into a big trouble. But, if someone tells you that they can hear a difference due to jitter, they are not talking out of their ass. They might not be actually hearing it, but they COULD be. There is a big difference between possible and impossible, and that was the point I was trying to make here.