# The mathematics of jitter



## lycan (Dec 20, 2009)

Hey guys, our heated debate in another thread got me thinking (you know that's trouble). Actually, got me to blow the dust off a few old chambers in my mind that have gone unused for too long  So I thought about doing a thread with the following goals :

1. Introduce the topic of jitter
2. Provide the mathematical foundation for the analysis of jitter
3. With the forum's help  create a few files of jittered signals that we can listen to ourselves !!!

This thread will not be combative  because there will really be very little room for disagreement. I'll state right from the start that the files we create may NOT be representative of real-life signals (like complex music), but they WILL demonstrate some principles and allow us to analyze some "worst-case" conditions. And we'll be able to LISTEN for ourselves !!!! 

We will absolutely be able to establish some "boundaries" on how much jitter is indeed audible (listeners of the files we create will be encouraged to do some double-blind experiments), at least for the range of _simple_ signals that we'll create. Our signals will be sinewaves of varying frequencies and amplitudes. These signals, and the results we obtain, are not "unfair", for two reasons :

1. Any complex signal (including music) is nothing but a combination of sinewaves
2. The signals we create are absolutely "allowed" by the digital audio standards we operate within

HOWEVER, the results, again, may be a bit "unrealistic" in the worst-case sense ... very much like testing analog electronics with full-scale sinewaves. You'll see what i mean as we progress. But we'll definitely learn some things along the way !!!

And fear not ... the math won't be too hard. Plus I'll do _most_ of it 

Are you guys game?


----------



## thehatedguy (May 4, 2007)

Yeap, down with it.


----------



## gymrat2005 (Oct 4, 2009)

fo sho! I'd love to participate in both the discussion, and whatever testing may be performed.


----------



## nirschl (Apr 30, 2009)

Absolutely, these are the type of threads that make me really appreciate this fine site. 

Keep it coming there "lycan-sensei!"

Cheers!

Pete


----------



## bboyvek (Dec 16, 2008)

subscribed.

Threads like this were the reason I got into car audio


----------



## SoundChaser (Apr 3, 2009)

I,m dddown...o:


----------



## coefamily (Sep 24, 2009)

bring it!


----------



## Austin (Mar 12, 2009)

subscribed. Haven't heard of jitter before so i will be learning a lot.


----------



## Neel (Mar 4, 2009)

subscribed, cant wait to learn more about jitter!


----------



## lycan (Dec 20, 2009)

*INTRODUCTION TO JITTER*

Before we talk about "clock jitter" in digital audio systems, a _very_ quick review of "sampling theory" is in order 

*Sampling Theory*

It's a well known theorem in signal processing that a bandlimited signal ... being a signal with zero frequency content above some point, let's call it *Fb* ... can be completely represented and recovered by _sampling_ the signal, in time, at a _sampling rate_ of at least 2**Fb*. This "Nyquist Theorem" (more accurately, Nyquist-Shannon Theorem) is the entire, fundamental foundation for digital audio  It means that we don't have to store and/or transmit the "whole" signal vs. time ... instead, we only need store and/or transmit _samples_ of the signal, and we can rest assured that we've captured _all of it_ 

It still causes a lot of confusion and doubt, but theorems are kinda hard to argue with ... 

*Clocks*

The hardware we need to "sample" the original audio waveform vs. time, starts with something called a "clock". It samples the audio waveform at a specific rate ... historically, 44.1kHz (which is slightly more than required by the Nyquist Theorem, to capture 20kHz audio) but more recently 48kHz, 96kHz even 192kHz. We have a variety of hardware "clocks" available to us in electrical engineering, the most accurate one being a _crystal oscillator_.

It must be immediately pointed out that we actually need _two_ clocks for digital audio capture & reproduction. The _first_ clock controls the analog-to-digital converter (ADC) that samples or "captures" the original signal vs. time (at the studio end), and a _second_ clock is needed to "playback" those samples at the precisely-correct time points, by controlling the digital-to-analog converter (at the consumer end).

It wouldn't be too far off-the-mark to suggest that the whole issue of jitter arises because these two clocks are NOT ... in fact, can NEVER be ... the same physical device. There will _always_ be some difference between these two clocks, just as there will always be some difference between any two wristwatches 

The basic Nyquist Sampling Theorem assumes that the clocks for capture & reproduction are perfectly accurate, and identical. The study of jitter is really the recognition that, in practice, this is _never_ the case.

more introductory stuff to follow ...


----------



## gymrat2005 (Oct 4, 2009)

....carry the 2...divided by...square roo....okay got it! 


Great start to the thread Lycan!


----------



## TREETOP (Feb 11, 2009)

I used to work with a guy named Dusty Vawter, back in 1990-1993 or so. Super cool guy but a little too smart for his own good (maybe?). 
He used to talk about a lot of things I didn't understand at the time (I was in my early 20s and mainly into volume over SQ) but jitter was one of the things he helped explain to me in regular english. His description was similar to yours, Lycan.
He moved on from the audio shop we worked at to start Audio Alchemy (he's currently at Channel Islands Audio), and soon after I acquired an Audio Alchemy DTI jitter processor and a DAC-in-the-box. My ears and mind were opened at that time to the realization that there's SO MUCH more to learn than what I'd previously thought. I miss being around people that I can learn from, I was like a sponge in the '90s.


----------



## Austin (Mar 12, 2009)

So this "Jitter" you speak of equates to noise in the system?


----------



## thehatedguy (May 4, 2007)

You know when people say that cables and terminations don't matter in digital audio because it's all 1s and 0s? Well in a perfect world and perfect transmission it would be a whole 1 and a whole 0. Think of jitter as the errors in the decimal places on the other side of the 1 and 0.


----------



## Austin (Mar 12, 2009)

thehatedguy said:


> You know when people say that cables and terminations don't matter in digital audio because it's all 1s and 0s? Well in a perfect world and perfect transmission it would be a whole 1 and a whole 0. Think of jitter as the errors in the decimal places on the other side of the 1 and 0.


so you are saying the best cable in a perfect world would/should send an exact 1 or 0 to the other end?

and that there are cables that corrupt these perfect 1's and 0's and that is called jitter?

Edit: or that the original signal (i.e. cd deck, carputer...) is corrupt to begin with?


----------



## usacimember (Dec 24, 2009)

interesting post indeed...


----------



## lycan (Dec 20, 2009)

Austin said:


> So this "Jitter" you speak of equates to noise in the system?


we don't know that yet  in some ways yes, in some ways no. Stay tuned, as we develop it further.

Yes ... it will be more than a "one post thread"


----------



## lycan (Dec 20, 2009)

Austin said:


> so you are saying the best cable in a perfect world would/should send an exact 1 or 0 to the other end?
> 
> and that there are cables that corrupt these perfect 1's and 0's and that is called jitter?
> 
> Edit: or that the original signal (i.e. cd deck, carputer...) is corrupt to begin with?


bad analogies 

one's and zero's are just that ... 1's and 0's. For them to be recognized as anything but, by a purely _digital_ system, would require errors far beyond anything we'll address in this thread. That's NOT the problem.

But what if the "clock" for the DAC depended strongly on precisely WHEN those 1's and 0's arrived ... down to the very nanosecond, or even more precise? A purely digital system may not care _exactly_ when that data arrives, as long as it arrives before some pre-determined event.

*But what if the very EXACT timing of an analog system depended completely on exactly and precisely when those one's and zero's arrived, at the end of transmission cable? What if the second clock in my introductory post above, was completely defined by precisely when some data arrives? What if the DAC clock is, in this way, "embedded" in the data? Then, the digital data stream is "carrying" MUCH more information than just one's and zero's  *

But we're getting a bit ahead of ourselves. For now, by way of analogy, imagine a real clock at some "source" location. It's an "atomic clock", the most precise clock known to man. It's used to control the timing of some system at the source. And there's a second "system", down the street, that we would like to be "timed" with equal precision. So we line up a bunch of people, down the street. Every time the atomic clock "tics", each person tells the guy next to them, all the way down the street. And at the end of the street, the last guy tics the second "system". Now tell me, will the second system be "timed" or clocked with equal precision as the first? After all, the stream of people on the street are only passing "digital" tics ... right? Or, are they passing MUCH more than just tic/no-tic info?

I'll hold off on more answers, until i finish my introduction ... later tonight


----------



## kyheng (Jan 31, 2007)

Jitter - Wikipedia, the free encyclopedia


----------



## lycan (Dec 20, 2009)

*INTRODUCTION TO JITTER (con't)*

To finish the introduction, we need to define what jitter is a little more precisely, determine where it might come from, and list some of its attributes.

*Simple example*

Let's say you "capture" the digital audio samples in the studio at exactly 44.100kHz. You _expect_ that they will be replayed, at the exact same rate. But what if the "clock" for the DAC in the consumer electronics gear has a frequency that's a _little_ bit different ... say 44.103kHz? Certainly not going to be an audible issue ... in fact, pure frequency errors are not really even recognized as "jitter", per se. But the point is ... has any accuracy been lost, in an absolute sense? What if the DAC clock plays-back the samples at 30kHz, instead of 44.1kHz? Think you can hear a difference?

I mention this example only to get you thinking about the need for good clock "alignment", between what was recorded, and what is played back. And to get you thinking about the "limits" of what might be audible, versus inaudible.

*Let's define jitter*

For our purposes, we _could_ define jitter as _any_ difference between the studio clock that "captures" or records the audio, and the consumer-end clock that "plays back" the audio. But it turns out that absolute frequency errors (mentioned above) tend to be a non-issue (they are almost always small enough in practice to be completely benign). A bigger, potentially more audible problem, is the type of jitter that results in so-called "phase noise" (rather than frequency error) between the clocks in question. Here's what I mean:

Imagine a "perfect" 44.1kHz clock, ticking along in the studio, "capturing" the audio samples. The first sample is at t=0. The second sample is 22.67574 microseconds later. The next sample is 45.35147 microseconds later, and so on. Each sample is taken exactly (1/44,100) seconds apart.

But when we go to replay that CD which was recorded with perfect timing, maybe our DAC clock behaves like this : first sample is at t=0. The second sample is 22.68 microseconds later. The next sample is 45.34 microseconds later. Indeed, what we have is some "phase" or "period" noise in the playback clock. What will _that_ sound like? (that's what we hope to find out in this thread).

_So we can define "jitter" as phase noise, or simply period-to-period errors, between the recording clock in the studio, and the playback clock in the consumer gear._

*Where does jitter come from?*

Here's the problem ... we need more than one clock, to both record & playback audio signals! Ideally, an engineer would be motivated to use a VERY good crystal oscillator clock at the ADC in the studio, and a separate ... but still VERY good ... crystal oscillator at the DAC in the playback equipment. They could never be perfectly synchronized to operate at the _exact_ same frequency, but small frequency errors are pretty benign. Crystal oscillators have very LOW period-to-period phase noise  (because they are electrical circuits with ridiculously high Q).

But alas, that's not how the digital audio standard was defined  The digital audio standard recognized that we actually need a _third_ clock in the system ... one to read the data off the CD transport. Now, at first glance, it would seem to be that the DAC clock needs to be well-synchronized to this transport clock (or else the DAC might not "keep up" with the data spewing from the transport), so the S/PDIF standard (that was spawned in hellfire) decided to put the clean, crystal oscillator at the transport, and just blast the data at the DAC. Some circuitry "near" the DAC would "recover" a timing clock from the data stream, and use _that_ "derived" clock to define the precise instants when digital becomes analog again. It's just stupid, but it does save one conductor in the system 

So basically, jitter or period-to-period phase noise arises because the clock that times our DACs is not "clean" ... there's some small period-to-period timing errors, that do _not_ match the master clock from the studio.

Analyzing these errors is what's in store next for this thread  

*But first, a few more random points about jitter :*

1. Although jitter is a problem unique to digital audio (well, to be fair, wow & flutter from tape & LP days could be argued to live in the same sandbox), it's an ANALOG problem, not a digital one. More specifically, it only manifests at the digital/analog interface boundary. Purely digital transfer, and purely digital analysis of data files, won't show any signs of jitter ... unless it's SO BAD that real data errors occur, but that's beyond the realm of concern these days.

2. As we've defined it, jitter is a phase noise difference between two clocks ... capture & playback. In most practical applications, the jitter is actually introduced upon playback. I would imagine that most studios use a pretty clean, precise clock for audio capture. It's the "recovered clock" driving the DAC in lots of some consumer audio gear that generates most issues of _possible_ concern. HOWEVER mathematically, the DAC clock could be perfectly clean, and the studio clock is noisy ... the analysis is really no different. And since it's my goal to help create some files we can listen to (and i can't get inside all of your consumer gear), the model of "noisy-capture/clean-playback" clock is the one we'll use for analysis. Fear not ... these are "mirror images" of the same problem.

3. In order to get a hint, or "feel", for the problem, let's ask a simple question : how do TIMING errors translate to AMPLITUDE errors, that we're more accustomed to dealing with in analog electronics? 

The answer is quite simple : *timing errors translate to amplitude errors through the SLOPE of audio signal being reproduced*. Slope is "delta *V* divided by delta *t*", where *V* is voltage and *t* is time. If a signal that's changing very FAST incurs some "error in time" upon playback, that _small_ TIME error can translate to a _big_ AMPLITUDE error ... simply because the signal changes alot, in a short period of time (delta *V* = slope * delta *t*). If, on the other hand, the signal is changing very slowly (imagine DC), a small error in playback time won't translate to a big error in amplitude ... the amplitude's almost never changing anyway, for that "slow" signal 

So we can immediately appreciate a STRONG "signal dependency" in how we expect jitter to manifest itself as audible "noise". It is NOT NOT NOT simply additive, like thermal noise in analog electronics. *How jitter might rear its ugly head, depends ALOT on the signal being played back*. We'll develop this much better in the next section.

4. Finally, a brief history. When digital audio first came on the scene in the 80's, nobody (almost) even knew what jitter was, much less how to analyze and quantify it. Things improved in the 90's ... from overhype, to lots of crazy theories (that signal dependency complicated things quite a bit, compared to what many audio engineers were accustomed to), but also a few good papers on the topic. Nevertheless ... solid, thorough studies were few & far between. In the last decade, i'm sure the science & study have improved quite a bit ... and i'm no longer current  But that's OK ... the _analysis_ we'll do is fundamental and invariant, and our _listening tests_ will provide some very good boundaries on "how much is audible" 

Up next ... mathematics, the fun part


----------



## gymrat2005 (Oct 4, 2009)

Great post Lycan. It was a very easy read. 

Funny you mentioned the comparison between jitter, and wow and flutter. I almost brought that up in context in the other post. I remember flutter being very apparent audibly, in some cassette players where the capstan would have a very noticeable wobble to it. Almost like a hubcap that is out of round on a tire.

But I digress...more please!


----------



## Dryseals (Sep 7, 2008)

When I did navigation aids, a plane would send us a set of pulses. The two pulses were seperated by their own frequency developed in their crystal occilator (sp) and seperated by that time. Since no two ocilators are exactly the same freq, we used the time difference as thier recieving timer. That is, they would reject any other two pulses but their own. So they would send it to us, we would delay the return by a fixed time it and send it back.

You would think the same could be accomplished with a digital recording. Use the leading edge of the recording to generate the frequency (sampling rate). 

I'm sure some one could develope an algorithm to determine exact sampling rates. This must be were the math comes in and I step out.

You've done it now, I'm thinking bias on old tape heads, that magical 44KHZ number again.


----------



## lycan (Dec 20, 2009)

*JITTER MATH*

This will be the math post. No, it's not intended to confuse. At the end, we'll derive a (fairly) simple relationship that will allow us to build some "jittered files" that we can listen to  *So stick with us* ... no need to grasp all the gory details if you don't want to. The relationship at the end is what's important.

*1. Sinewave signal*

We'll start with a sinewave signal. This will be our "audio signal" that we're ultimately trying to faithfully reproduce :

Audio signal = *A**sin(*ws*t*) = *A**sin(*2pi*fs*t*)

where :
*A* = audio signal amplitude
*fs* = audio signal frequency
*t* = time

we can make life simpler, without losing any generality, by normalizing the amplitude from here on, so that : *A* = 1.

*2. Ideal sampler*

In signal processing, ideal sampling is represented as _multiplication_ by an ideal, periodic "impulse train". This impulse train is our CLOCK  It's represented mathematically as :

Ideal impulse train = delta(*t - n*T*)

where : 
delta is our impulse train
*n* = sample number
*T* = sampling interval = 1/(sampling rate)

so that our ideal sampled audio signal becomes :

Sampled audio signal, ideal clock = sin(*2pi*fs*t*)***delta(*t - n*T*)

A simple property of impulse trains allows us to re-write the sampled audio signal in simpler, perhaps more familiar terms :

Sampled audio signal, ideal clock = sin(*2pi*fs*n*T*)

*3. Jittered sampler*

To describe the non-ideal sampling process of interest, we need to "jitter" the sampling impulse train, so that the impulse arrival times are now "jittered" by a new "jitter sinewave" :

Jittered impulse train = delta(*t - n*T - b*T**sin(*2pi*fj*n*T*))

where :
*b*T* = jitter amplitude
*fj* = jitter frequency

so that our audio signal, sampled with a jittered clock becomes :

Sampled audio signal, jittered clock = sin(*2pi*fs*t*)***delta(*t - n*T - b*T**sin(*2pi*fj*n*T*))

which we can re-write as :

Sampled audio signal, jittered clock = sin(*2pi*fs*(n*T + b*T**sin(*2pi*fj*n*T*)), or
Sampled audio signal, jittered clock = sin(*2pi*fs*n*T + 2pi*fs*b*T**sin(*2pi*fj*n*T*))

Some may recognize this as a _phase modulation_ or _frequency modulation_ (FM) relationship  The jitter signal @*2pi*fj* is "modulating" the phase of our audio signal  that bastard!

We can SIMPLIFY this relationship by employing a classic trig identity:

sin(*x + y*) = sin*x**cos*y* + cos*x**sin*y*

which directly leads to :

Sampled audio signal, jittered clock = sin(*2pi*fs*n*T)**cos(*2pi*fs*b*T**sin(*2pi*fj*n*T*)) + cos(*2pi*fs*n*T)**sin(*2pi*fs*b*T**sin(*2pi*fj*n*T*))

see ... isn't that simpler? 

no, not yet  But we can make our FIRST & ONLY approximation, and that is : the jitter effect is SMALL. This means that : *2pi*fs*b*T* << *1*.

So now the relationship becomes :

Sampled audio signal, jittered clock = sin(*2pi*fs*n*T*) + *2pi*fs*b*T**sin(*2pi*fj*n*T*)***cos(*2pi*fs*n*T*)

This is our *final* result. And its a lot simpler than it looks 

*4. Interpretation*

The result says that sampling with a jittered clock is equal to a summation of the ideal sampled signal, plus an _amplitude modulation_ term (yes, phase modulation by a small amplitude is indistinguishable from amplitude modulation). In the amplitude modulation term, the "carrier signal" is our precious audio signal @ *2pi*fs*, and the "modulating signal" is our jitter signal @ *2pi*fj*. Note that the "amplitude" of the modulating signal is : *2pi*fs*b*T*, which is the _product_ of the jitter amplitude, *b*T*, and the audio signal frequency, *2pi*fs*. Remember when we said that the "effect" of the jitter is going to be _worse_ for faster-changing signals? Well, here it is 

Up next : we'll break this down, and outline how we can create some files for listening  TRUST ME ... it's a LOT simpler than it looks.


----------



## thehatedguy (May 4, 2007)

Pffff

Like you know something about digital audio "Mr. I designed a DAC in my day." 


lol.


----------



## lycan (Dec 20, 2009)

Who wants to help create some files ??? That way, we can LISTEN for ourselves !!!   How much jitter is indeed audible? 

Let's start VERY simple, so that we can nail down the procedure. Let's start by creating simple files of "_sampled audio signals, ideal clock_" from the last post.

All we need is this :

Sampled audio signal, ideal clock = sin(*2pi*fs*n*T*)

*fs* is the audio signal frequency we'll be reproducing. I suggest we build THREE files, one for each of these frequencies :

*fs* = 1kHz, 4kHz, 16kHz

The parameter *T* is simply the inverse of the sampling frequency. You guys tell me, at what sampling frequency will it be easiest to replay some files? 44.1kHz, or 48kHz? 

*n* is nothing but the sample index : 0,1,2,3,4,5 ....

I suggest we create files that are 10 seconds long. All we need is a simple program, to create each sample according to the sinewave function above, in a format that's "playback friendly".

Who can be our huckleberry?  The thread needs you !!!!


----------



## gymrat2005 (Oct 4, 2009)

Okay, what do I need to do Lycan? What program will facilitate the creation of a jittered file? I hope there's no math involved cuz' you lost me right around that first asterisk I work 10-12 hours a day thurs-sun, but I'll get er' done as soon as I am able. Also, I plan on having a friend do the listening. I trust his ears and that he'll notice a difference if there is in fact one to be heard. I will not tell him why or to what I am having him listen to. He will just listen and tell if he hears any difference.


----------



## nsaspook (May 19, 2009)

lycan said:


> Who wants to help create some files ??? That way, we can LISTEN for ourselves !!!   How much jitter is indeed audible?
> 
> Let's start VERY simple, so that we can nail down the procedure. Let's start by creating simple files of "_sampled audio signals, ideal clock_" from the last post.
> 
> ...


Low jitter clock recovery in audio is child's play, try it at 96Gb/s.

http://ofc.optics.ucf.edu/research/11.pdf


----------



## lycan (Dec 20, 2009)

lycan said:


> Who wants to help create some files ??? That way, we can LISTEN for ourselves !!!   How much jitter is indeed audible?
> 
> Let's start VERY simple, so that we can nail down the procedure. Let's start by creating simple files of "_sampled audio signals, ideal clock_" from the last post.
> 
> ...


This ^^^^^^^ is what we need 

*One step at a time. The first file will NOT NOT NOT be jittered.*

The *first* file (or 3 files, as above), described in the quoted post above, is what we need. We need a simple program to create a long list of samples, according to the simple sinewave function described above in the quoted post. If you don't know what i mean, you're probably thinking too hard 

In short : our FIRST step is to create a file that plays NOTHING BUT the simple tone described in the quoted post above. The FIRST step is to ignore jitter, forget you ever heard about jitter, and create a long list of samples (i've suggested 10 seconds worth) of the SIMPLE, PURE tone described in the quoted post above.

What will be involved, I imagine, is a simple C program (maybe matlab, maybe any other language) ... no more than about 7 lines ... that will WRITE these "sinewave samples" into a file, that can be ultimately "translated" into a .wav file. Or perhaps, there's a program that can directly write the output of a C program into a .wav file?

If anyone can point me to "how to create a .wav file", i'll do it  But i'm not talking about creating a .wav file from a DVD or ipod  I'm talking about creating a .wav file from a PROGRAM that performs calculations 

Please re-read this, several times as necessary


----------



## lycan (Dec 20, 2009)

seems there is a matlab routine called "wavwrite" that can write/create a .wav file  might be just what the doctor ordered ... i'll do some research, blow the dust off my matlab software.

EDIT : yep, this looks to be trivial with matlab. The program will be less than 10 lines long, and it looks like matlab can "directly" create a .wav file (for listening) with wavwrite  I'm sure I gotta renew my matlab license, and remember how to write a matlab program  If anyone is more immediately familiar, please jump in !!!

The equations i've presented are _trivial_ to write ... almost verbatim ... in matlab. The bigger hurdle is making sure all the programs and files work & play well together


----------



## highly (Jan 30, 2007)

A good starting point for the C++ literate:
Clicky

I can verify it compiles and runs under Cygwin in Windows and on Debian Linux.

I'd jump in but I am teaching class at the moment, and it would take me more than 5 minutes to hack this into something workable. My wife's the coder...

-Todd


----------



## lnaesll (Apr 2, 2010)

wow this is an awesome thread! i joined this site just to stay up to date on this! think imma stick arround for a while.


----------



## daudioman (Mar 17, 2008)

This is awesome! I'm an EE student and I JUST took a test on this stuff (Nyquist, z transformations, sampling, etc...). I 'm just happy that I can use this stuff with the mobile audio stuff I love!!! 

lycan: I *need *you to be my tutor for filters/matlab/controls...etc!!! What are your rates??? ;-) 

KEEP BRINGING IT WE NEED MORE ARTICLES LIKE THIS!! Especially the parts about what is actually audible vs. inaudible for example. Thanks again!


----------



## stoeszilla (Jul 9, 2007)

Could we not use audacity to create the required 10 second clips?

I tried to attach .wav files but was told these were "not valid". When I zipped them together, the file size was too huge...argh! 

I'll try mp3 format...


----------



## lycan (Dec 20, 2009)

stoeszilla said:


> Could we not use audacity to create the required 10 second clips?
> 
> I tried to attach .wav files but was told these were "not valid". When I zipped them together, the file size was too huge...argh!
> 
> I'll try mp3 format...


wtf is audacity?

i'm too old for this game


----------



## Austin (Mar 12, 2009)

lycan said:


> wtf is audacity?
> 
> i'm too old for this game



A great sound processing/editing program:

Audacity: Free Audio Editor and Recorder


----------



## lycan (Dec 20, 2009)

Austin said:


> A great sound processing/editing program:
> 
> Audacity: Free Audio Editor and Recorder


Does it allow you to create a .wav file (or any other file that can be listened-to), from a simple calculation of sinewave functions? We aren't trying to create listening files from : microphones, dvds, playlists, ipods, or other mp3 devices. We need to create a "listening file" from a _mathematical function_, or description, that is written in "some" programming language. And honestly, the "program" will be shorter than this paragraph i just wrote.

The file we _create_ can then be _played_ on a PC or any other audio device ... except that I would discourage any file compression during playback.

I know matlab can do it ... i just gotta revisit all the matlab details about licensing, file formatiing & creation, etc.


----------



## Austin (Mar 12, 2009)

lycan said:


> Does it allow you to create a .wav file (or any other file that can be listened-to), from a simple calculation of sinewave functions? We aren't trying to create listening files from : microphones, dvds, playlists, ipods, or other mp3 devices. We need to create a "listening file" from a _mathematical function_, or description, that is written in "some" programming language. And honestly, the "program" will be shorter than this paragraph i just wrote.
> 
> The file we _create_ can then be _played_ on a PC or any other audio device ... except that I would discourage any file compression during playback.
> 
> I know matlab can do it ... i just gotta revisit all the matlab details about licensing, file formatiing & creation, etc.



I am by far no expert at audacity, but i do know it is a powerful program. I'm not sure if it can create a listening file though. someone with more experience with it would have to step in on that one. I just use it to cut and edit songs to make ring tones :laugh:


----------



## mosca (Oct 26, 2009)

I've found a little Python script to generate audio files from programmatically. I've tried it and it works perfectly, we just need to get the new formula right (I think). I'm pasting the full code here (it does what is says between the """ lines):


```
# create a soundfile in AU format playing a sine wave
# of a given frequency, duration and volume
# tested with Python25   by vegaseat     29jan2008
 
from struct import pack
from math import sin, pi
 
def au_file(name='test.au', freq=440, dur=1000, vol=0.5):
    """
    creates an AU format audio file of a sine wave
    of frequency freq (Hz)
    for duration dur (milliseconds)
    at volume vol (max is 1.0)
    """
    fout = open(name, 'wb')
    # header needs size, encoding=2, sampling_rate=8000, channel=1
    fout.write('.snd' + pack('>5L', 24, 8*dur, 2, 8000, 1))
    factor = 2 * pi * freq/8000
    # write data
    for seg in range(8 * dur):
        # sine wave calculations
        sin_seg = sin(seg * factor)
        fout.write(pack('b', vol * 127 * sin_seg))
    fout.close()
 
# test the module ...
if __name__ == '__main__':
    au_file(name='sound800.au', freq=800, dur=2000, vol=0.8)
 
    # if you have Windows, you can test the audio file
    # otherwise comment this code out
    import os
    os.startfile('sound800.au')
```


----------



## lycan (Dec 20, 2009)

mosca said:


> I've found a little Python script to generate audio files from programmatically. I've tried it and it works perfectly, we just need to get the new formula right (I think). I'm pasting the full code here (it does what is says between the """ lines):
> 
> 
> ```
> ...


hey! whatever the hell a "Python script" is (i really am too old for this), this little nugget has promise !!! Let me look at it a little closer, but i think our "mods" will be simple indeed 

Remember, we're gonna start slow ... walk before run. I want to make sure we can create a simple, CLEAN sinewave (or "tone") signal first, before we "jitter" it.


----------



## highly (Jan 30, 2007)

Anyone happen to know the allowable magnitudes for .wav files? Based on the results I am getting in C we are going to have to scale the output of the formula. Should we aim for a level of of 0dB or -10dB? 

I have been pressed for time between the build (car), the show this weekend (!!!) , work and sleep (as much as I have tried to avoid it!) but I have been working at it during breaks (food).

I like the looks of the Python code, but I just don't know enough Python to be of any real help with it, so I'm taking the road I know.

-Todd


----------



## highly (Jan 30, 2007)

Almost there. Minor issue of the sine wave duration that I need to iron out, but should be posting something tonight.


----------



## gymrat2005 (Oct 4, 2009)

cool man, glad you are helping out with this project.


----------



## highly (Jan 30, 2007)

OK, I've got it running like it should, but it's built in Cygwin. Anyone know of a nice, small C compiler for Windows? I might have to break down and in stall the VC++ IDE from MS.

<edit> 
OK, here we go. This is a link to my personal home server, so please don't abuse it.
Clicky
You will require WinZip or similar that can open a tarball.
This is a console application and will create the .wav file in the directory you run it from.
Check it out and let me know if there are issues/problems/concerns before we move forward.
</edit>


----------



## highly (Jan 30, 2007)

Looked back over the thread and saw this:


Lycan said:


> sin(2pi*fs*n*T) + 2pi*fs*b*T*sin(2pi*fj*n*T)*cos(2pi*fs*n*T)


If this is the 'simplified' jittered-wav formula I will get started with attempting to implement it. BTW, for the C-literate, the very ugly source code is available by request. I'm more than happy to share.

Finally, I'd like to thank my lovely wife "K" or helping me to sort out the "Little Indians" on this one. I am NOT a programmer, and the .wav file format requires you send data with the correct endianness. Without her I'd still be battling this. I love that woman (and not just for her beautiful mind)!


----------



## highly (Jan 30, 2007)

...crap. Used the MS compiler and it broke the .wav output! Why does this not surprise me. 
Here is the working version, but it is compiled for Cygwin. You will need Cygwin to run it.

Sorry. I'm trying to find a free Windows C compiler that doesn't suck.


----------



## gymrat2005 (Oct 4, 2009)

Thanks "K"! 

I tried to install Cygwin, and it is throwing parse errors (syntax error, unexpected OPENSQUARE, expecting $send)


----------



## highly (Jan 30, 2007)

In Cygwin, put quick.exe in your home directory (C:/cygwin/home/<username>) and start cygwin. Type ./quick.exe and it should "just work". If it doesn't, email me at tluliak at google's mailserver.
-Todd


----------



## highly (Jan 30, 2007)

OK, I fixed the Windows app and updated the original link. It's the same as THIS one.

I hate programming IDEs. Gimme a command line on a Unix box and I am happy.

I must be getting old.

Let me know how it works (or fails to work!)
-Todd


----------



## highly (Jan 30, 2007)

Well, I have learned a lot already! First of all, I have been using WaveLab to view and verify the output files. There is a little bit of frequency dependent drift in the output files that I was looking into correcting, so I was making higher frequency files to see how much the drift accrued. When I open a 15Khz file in WaveLab and zoom in to the waveform, there are only a handful of samples to define one period of the sine wave. 44100 samples per second divided by 15000 cycles per second is 2.94 samples per cycle. That makes a sine wave that looks like a stairmaster program. I am impressed how inaudible THAT is! 

This is kinda neat  
Can't wait to get to the listening part!


----------



## lycan (Dec 20, 2009)

hey guys, thanks for the effort! I'll get back to this within a day or two.

BUT ... WALK FIRST. Then run  Make sure you know how to create the SIMPLE sinewave first. The one with NO jitter. It's posted above


----------



## highly (Jan 30, 2007)

Take your time; I need a break! All this walking has been taking it outta me!
-Todd


----------



## mosca (Oct 26, 2009)

here's some guys that wanted to do some tests with "jittered" files too Audibility of Jitter - Hydrogenaudio Forums

it seem they never got through them, but there's some discussion in the thread.


----------



## lycan (Dec 20, 2009)

alright guys, now i'm lost.

Back in the day, we would create long files with simple C programs, and listen to them 

What the **** is Cygwin?  Please somebody just post some code again, and i'll review it.

So let me do this, for now. Here's what I recommend :

1. Create a file of the simple, unjittered sinewave first. Pick these three frequencies, and create three files : 1kHz, 4kHz and 16kHz. Pick an amplitude that's hot, but a bit less than full scale ... say, 80% of full scale.

The relevant realtionship is this :

*y = A**sin*(2pi*fs*n*T)*

where *2pi*fs* is the signal frequency ... 2pi*1khz, 2pi*4kHz, and 2pi*16kHz ... and *T* is the inverse of the sampling rate. It doesn't get any simpler than this 

2. After this "process" has been established, it's time to jitter and listen! The formula for the _jittered_ sinewave has been posted above. And i'll tell you this : the worst case "carrier" frequency is going to be the 16kHz sienwave signal 

In this case, we'll ALSO have to pick an amplitude and frequency for the jitter signal. The amplitude will ultimately be in nanoseconds (time), because we are "modulating" a timebase. Different files can readily be created, so that different "levels" of jitter can be heard ... to determine an "audibility threshold" of jitter 

All that remains, is what jitter FREQUENCY to pick ... *2pi*fj*? I'll tell you guys the worst case for audibility, but you'll have to ask me ... that way I know that these posts are really being read  It's an old trade secret, for the "worst-case bound" on the audibility of error artifacts, like this


----------



## highly (Jan 30, 2007)

Lycan-
Download the file from Post 48. It's a tarball; open it with WinZip or WinRar and extract the executable file. Run it and all will be clear.
Source code (in C) is available HERE
-Todd


----------



## lycan (Dec 20, 2009)

highly said:


> Lycan-
> Download the file from Post 48. It's a tarball; open it with WinZip or WinRar and extract the executable file. Run it and all will be clear.
> -Todd


i tried ... and failed 
something blew up. Not configured right, not un-zipped to a place i recognize, execution files all munged up, who the hell knows.

If anyone can cut and paste the 7 lines of code (written in some parallel universe that's foreign to me, no doubt), i'll do by best to critique the code.

Just don't ask me to download, unzip or execute 

Funny thing is, i knew this would happen  The math is practically trivial, compared to file formatting, downloading, executing, operating system compatibilities, yada yada yada


----------



## highly (Jan 30, 2007)

It's not 7 lines of code. It's 2 .c files, a header file, and a makefile. The sine wave is trivial, but output to a .wav file format....wasn't.


```
for (i = 0; i < N; i++)
    {
	//sin(2pi*fs*n*T) + 2pi*fs*b*T*sin(2pi*fj*n*T)*cos(2pi*fs*n*T)
	tmp = (sin(.000142475857305659562 * FREQ * i)); //<-simplified
		//tmp = (sin(((2*PI)*(FREQ*i))*INV)); // <--unsimplified
					        /* round float to long, cast to short.*/
	//ans[i] = (short)lroundf(tmp * 32750);   /*32768 is max scale (signed 16 bit)*/
	ans[i] =(short)(tmp*30000); //Scaled to ~80%
 
}
  printf ("%d samples processed.\n", i); 
 /* Write the output to the file*/

  write (fd,ans,N * 2);
```


----------



## lycan (Dec 20, 2009)

highly said:


> It's not 7 lines of code. It's 2 .c files, a header file, and a makefile. The sine wave is trivial, but output to a .wav file format....wasn't.
> 
> 
> ```
> ...


I'm back on board  thank you, good sir!

I got the jittered signal, i got the amplitude scaling (rounded to integers, 16-bit binary equivalents for a base-10 max amplitude of 32768). And i got your sample rate of 44.1kHz (*T*=1/44,100) VERY GOOD !!!!!

Remember that the first term in the jittered expression is the "clean", unjittered sinewave ... the "simplified" case  The only "parameter" you need to specify for that term is *fs*. Did you successfully create a set of files for 1kHz, 4kHz, and 16kHz signals, at about 80% full scale? Do they "sound" like they should ... clean tones?

Sorry for emphasizing the need to move slowly  I just want to make sure our framework is working, before we introduce the complexity of jitter.


----------



## stoeszilla (Jul 9, 2007)

lycan said:


> wtf is audacity?
> 
> i'm too old for this game


Sorry, I got to this too late. You're too old for this game? Jeebus, the content of this thread is not for the faint of heart. Most of your posts aren't either, Lycan, but I ALWAYS read them because they are informative as hell. Usually read them at least 3 times just to get it...

Moving on, audacity is free, cross-platform (windows, mac, linux, etc.) audio editor program. You can get it here: Audacity: Download

To create the desired sine wave, go to "Generate/Tone". 

Select waveform ("sine"), choose your frequency in Hz, amplitude (0-1) [note: I have not messed with this at all to see what it does. I just leave it at 1], and length (seconds). 

Click "Generate Tone" and shazzam, you have just created your sine wave/tone of choice. 

Next, click on "File" and export to format of your choice (.wav, .mp3, ogg vorbis, etc.).

Easy, peasy, lemon-squeezy.

This may be after the fact, but better late than never...hope this helps.


----------



## t3sn4f2 (Jan 3, 2007)

stoeszilla said:


> Sorry, I got to this too late. You're too old for this game? Jeebus, the content of this thread is not for the faint of heart. Most of your posts aren't either, Lycan, but I ALWAYS read them because they are informative as hell. Usually read them at least 3 times just to get it...
> 
> Moving on, audacity is free, cross-platform (windows, mac, linux, etc.) audio editor program. You can get it here: Audacity: Download
> 
> ...


Can't really use it since there is no way to add the jitter.


----------



## mosca (Oct 26, 2009)

highly said:


> Lycan-
> Download the file from Post 48. It's a tarball; open it with WinZip or WinRar and extract the executable file. Run it and all will be clear.
> Source code (in C) is available HERE
> -Todd


hey highly, is 'io.h' par of Cygwin? I've tried to compile on Mac OS X, but it fails:


```
$ make
gcc -O2 -g   -c -o wav.o wav.c
wav.c:5:16: error: io.h: No such file or directory
make: *** [wav.o] Error 1
```


----------



## highly (Jan 30, 2007)

io.h is the header file that has the definitions for file input/output operations. It is not specific to Cygwin, but it may have another name or be in a subdirectory of wherever the headers are kept on your system. I'm not 'mac-aware', though. You should be able to head to your compiler directory (possibly /usr/include or similar?) and grep for "fd" to locate the file that handles those definitions. Then just replace the include from io.h to whatever it is on your system. 
Hope that helps a little!
-Todd


----------



## mosca (Oct 26, 2009)

thanks highly, I'll take a look. actually Mac OS X is a BSD Unix, so the simple stuff usually works.


----------



## mosca (Oct 26, 2009)

strange, I couldn't find anything useful, so I just commented that line and it worked! (or so it seem, now I have an executable named _quick_, which I have executed, and after entering "1000" and pressing any key"  I got a _jittertest.wav_ file.

this is what I have now in _wav.c_


```
#include <stdio.h>
//#include <io.h>
```
and here is the execution of _quick_:


```
$ ./quick
Let's create a sine wave tone in .wav format. You will need to provide some data first.
Please enter the frequency for the sine wave in Hertz followed by the enter key: 1000
We'll be creating a 10 second sample at 1000 Hertz.
 The file will be called jittertest.wav in the current directory.
                Press any key to continue! 


Chunk size = 882036
Format chunk size = 16
Format tag is 1 = WAVE_FORMAT_PCM Microsoft
Number of channels = 1
Sample rate = 44100
Average bytes per second = 88200
BlockAlign = 2
Sample size = 16
Data size = 882000
441000 samples processed.
882000 audio bytes written to file.
```


----------



## highly (Jan 30, 2007)

Looks good! Did you give it a listen and see if it actually produced output? It should make clean sine wave files with no jitter or appreciable drift. I have noticed that the higher the frequency, the lower the frequency accuracy. 100 Hz is really 100.0x Hertz, and 1000 Hertz is 1001-1002. 10K Hz is still less than 10100 Hz. I'm guessing it's significant digit errors along the way even though I am using floats to 18 significant digits! It all makes a difference, but I have to cast to short to write the file. The rounding error is an amplitude error, though, so it has no effect on frequency accuracy.

As soon as I have the chance I will be expanding it to also do jittered files, but I want a couple of people to evaluate the "clean" output first. I'm NOT a programmer so errors are likely.

-Todd


----------



## t3sn4f2 (Jan 3, 2007)

Lycan, here's a little on USB DAC tech you asked about the other day. Thought I'd put it here since it's more on topic.

Wavelength Audio, USB DACS, Computer Audio Concepts


----------



## mosca (Oct 26, 2009)

highly said:


> Looks good! Did you give it a listen and see if it actually produced output? It should make clean sine wave files with no jitter or appreciable drift. I have noticed that the higher the frequency, the lower the frequency accuracy. 100 Hz is really 100.0x Hertz, and 1000 Hertz is 1001-1002. 10K Hz is still less than 10100 Hz. I'm guessing it's significant digit errors along the way even though I am using floats to 18 significant digits! It all makes a difference, but I have to cast to short to write the file. The rounding error is an amplitude error, though, so it has no effect on frequency accuracy.
> 
> As soon as I have the chance I will be expanding it to also do jittered files, but I want a couple of people to evaluate the "clean" output first. I'm NOT a programmer so errors are likely.



yes *highly*, the file actually contains a synewave tone 

regarding accuracy: can't you round the freq calculations?


----------



## highly (Jan 30, 2007)

mosca said:


> yes highly, the file actually contains a synewave tone


Yay!



mosca said:


> regarding accuracy: can't you round the freq calculations?


Hmm, not sure exactly what you mean. I'm trying to maintain the frequency as dead-on as possible. It's the lack of numerical accuracy in the calculation that results in the output not being the exact frequency specified by the user (I think). I'm only rounding and casting the floating-point result to type short at the last possible moment to try to keep as on-frequency as possible. Any rounding there should affect the amplitude of the sample and the resultant sample should be better than 1/32767 accurate at that point.
At a requested frequency of 1000 Hz I get 1000.09Hz out. At 10,000Hz requested I get 10271.64 Hz. I'm not sure how I can do better, but I will try using more significant digits in the constants and see if that reigns it in. There isn't any way to round the resultant wave back down to 10,000 Hz, though, as we need more <frequency> accuracy per sample to achieve the result we want. I think. Lol!

That make any sense or am I thinking one-dimensionally again?

If you have a piece of software (or hardware) that you can use to measure the frequency of the output sine waves to verify my findings, that would be a good thing. I'm using wavelab, selecting the duration, and doing a Global Analysis to find resultant pitch.


-Todd


----------



## mosca (Oct 26, 2009)

ok *highly*, I understand now (well, mostly ). I'll see if I can find any Mac specific software that lets me check the pitch.


----------



## highly (Jan 30, 2007)

Something's just _not right_ and I am not enough of a coder to know what. Over 10KHz, things start getting odd. By 15K, it's plainly not right, and 20KHz is just freaky. It's as if there were a term causing an interference pattern that comes into play. The smooth sine waves start taking on a ripple that overtakes the primary tone in the 12-16K region. I'm going to have to back up and try outputting the array as comma separated data so that I can graph it for trends in Excel and maybe come up with something.
I am wondering if the variables are being declared as the proper type. I did some reading on double and float declarations and how they can mangle precision depending on what you are doing with them. I'm just not experienced enough to sort this out.

-Todd


----------



## mathematics (May 11, 2009)

i know i'm late on this chat. i thought that modern audio compression uses the MDCT (modified discrete cosine transform) ?


----------



## highly (Jan 30, 2007)

mathematics said:


> i know i'm late on this chat. i thought that modern audio compression uses the MDCT (modified discrete cosine transform) ?


I thought that was used for, as you said, compressed audio formats (like MP3). We're trying to create uncompressed PCM waveform data, so I am uncertain where that might fit into the equation (so to speak). I'm not mathematician, though, so please enlighten me if it is something I should be considering!

-Todd


----------



## mathematics (May 11, 2009)

I'm no expert or anything close on this subject, but it was just something that popped into my head from numerical analysis. i would think it would be something to consider since you are sampling analog signals to obtain a digital representation. i don't think lossy or lossless would matter, but i really am not sure. if you think about it, there really is no such thing as lossless-you will always lose information. i figured it would be something to think about, though. any thoughts?


----------



## highly (Jan 30, 2007)

I'd love to say I had an opinion one way or another, but I am completely ignorant of how it might be applied. The most math I've survived was Calc-I in high school, and that was a good 20 years ago. I'm fairly certain it would have to creep up on me and beat me senseless before I was even aware of it.
What we're after shouldn't be that difficult to accomplish, but I'm being confounded by C datatypes. What I've learned so far:

Floats are bad for precision. Store an int (500) in a float and dereference it and you will automagically grow digits to the right of the decimal point (500 becomes 500.00000024153 or some such nonsense). That's not "good". 

Division is stupid. 1/44100 in C = 0. If you want some number as a result, you have to do 1.0/41000. Who thought that was a good idea?!

The math works GREAT in Excel. Something I am doing in C is a problem, and I don't know what it is. Put in the same values in the app and in excel and you will get two different results. When freq=100 they will be very close. When freq=15,000 they won't.

That's the root of the problem. I think anything else just confuses the issue (at least for me). I know the math is good. The code clearly is not.

-Todd


----------



## kkant (Feb 3, 2008)

I think I see what's wrong. Looks like you're losing precision too early in your calculations:

//sin(2pi*fs*n*T) + 2pi*fs*b*T*sin(2pi*fj*n*T)*cos(2pi*fs*n*T)
tmp = (sin(.000142475857305659562 * FREQ * i)); //<-simplified
//tmp = (sin(((2*PI)*(FREQ*i))*INV)); // <--unsimplified
/* round float to long, cast to short.*/
//ans_ = (short)lroundf(tmp * 32750); /*32768 is max scale (signed 16 bit)*/
ans =(short)(tmp*30000); //Scaled to ~80%


I think everything should be handled *explicitly* with double values and variables until the final round and cast. That includes the scale to 30000, and it includes the factors inside the sin() call. Also, does the floating point library you are using have a sin() function that operates on double-precision values?

This might fix the problem you are having at high freqs with your C app. I suspect the reason it works in Excel (or Mathematica) is that Excel maintains maximum precision automatically and upcasts automatically when needed._


----------



## highly (Jan 30, 2007)

My wife "K" and I have been having discussions along a similar line. I've looked into an arbitrary precision math library called MAPM that I think looks promising. Clearly the VisualC math.h isn't very precise.

As a self-taught non-coder, it isn't innately obvious the degree of precision assigned to data types in C, and I haven't found a lot of examples that illustrate how that works for or against you in a given type of calculation. That's left me poking and prodding at it trying to get what I want and failing. The precalulated values were a stopgap measure to verify the rest of the code while I tried to sort out the precision issue.

If I have some time this weekend I will hit it again with the MAPM library using doubles and see if that helps. It all has to be cast to short in the end, but clearly the precision is required.

Thanks, and may you be Touched by His Noodly Appendage, Arr!

-T


----------



## lycan (Dec 20, 2009)

hey guys, thanks for keeping this thread alive 

I thought we would examine the "jitter term" a little more closely in this post. Here it is again:

*2pi*fs*b*T**sin(*2pi*fj*n*T*)*cos(*2pi*fs*n*T*)

Let's examine all the components of this "jitter term".

*JITTER AMPLITUDE*

The complete jitter amplitude is : *2pi*fs*b*T*

Couple things to note about the _jitter amplitude_ :

1. The "real" jitter amplitude is simply *b*T*. This is the peak jitter, in units of time. For example, if *T*=1/44.1kHz and *b*=0.000441, then our peak jitter is 10 nanoseconds. Understanding this allows us to create files with different amplitudes of jitter, to determine audibility thresholds  (By the way, peak-to-peak jitter, and rms jitter, follow the typical rules for sinewave amplitudes)

2. The "other" factor in the "complete jitter amplitude" is our signal frequency, *2pi*fs*. As we developed earlier, errors in _time_ (aka jitter) will translate to _larger_ errors in _amplitude_ for signals that change _faster_. This factor performs this "time-to-amplitude" translation for us 

*JITTER FREQUENCY*

Jitter frequency is : *2pi*fj*

Pretty self explanatory ... until you go searching for it in an FFT  Remember ... this jitter sinewave is _amplitude modulating_ the signal frequency, *2pi*fs*. This is indicated by the cosine expression in the jitter term above.

What this means is : Let's say you pick a signal frequency of 8kHz, for example, so that *2pi*fs*=2pi*8kHz, and you pick a jitter frequency of 1kHz so that *2pi*fj*=2pi*1kHz. Then you create the .wav file according to our calculations, and maybe perform an FFT on the output. You will see the signal frequency at 8kHz  but you won't see the 1kHz jitter artifact at 1kHz  You'll see it at 7kHz and 9kHz 

next up : worst case bounds, and why lots of the jitter discussion in the literature is practically worthless


----------



## lycan (Dec 20, 2009)

As we've seen ... jitter is a _complicated_ topic. I promise you ... most audio engineers don't understand it. Here's a few layers of complication:

1. A digital analysis of a file won't show any jitter artifacts that occur in transmission. Jitter is an _analog_ problem, and only manifests at analog/digital boundaries.

2. How much transmission jitter may, or may not, show up at an analog output of a DAC depends on : what type of digital receiver is used (and bandwidths of the PLL or ASRC used in that receiver), and what type of DAC is used (oversampled vs. nyquist, and current-steered vs. switched capacitor).

3. As we've seen, jitter fundamentally _modulates_ the audio signal. It's NOT a simple additive term. The math is a bit hairy, as are the observable artifacts.

*So ... the first question an inquisitive mind should ask, when reading any literature that hints at a jitter problem is this : How do we know they've captured, or addressed, the worst case scenario?*

And this brings us, finally, to the WHOLE POINT of this thread  We are now in a position to establish a "worst case bound" on jitter. Because we've done the math to analyze it  Admittedly, we are "creating" jittered files. What bearing do these files have on reality? The bearing is this : we can now establish a worst-case threshold for the audibility of jitter. It may be that no transports, no transmission systems, will ever approach this limit. But we will be able to _find_ this limit, and state with certainty that any jitter amplitude _below_ this limit will, in fact, be inaudible.

1. *Worst-case signal frequency, fs*. The worst case signal frequency is the highest one  This is because of that *2pi*fs* factor that shows up in our "complete jitter amplitude" above. This is because _time_ errors translate to _amplitude_ errors through the _slope_ of the audio signal.

But let's not get too crazy : feel free to set *fs=16kHz* as the "worst case" signal frequency.

2. *Worst-case jitter frequency, fj*. I'm gonna tell you guys a trade secret. How do you "pick" a frequency for an artifact you are trying to observe ... indeed, an artifact you are trying to "bound"? It's simple ... you pick ALL OF THEM 

The "worst case" jitter frequency is a sinewave SWEEP over the whole audio band. Why a sweep? Two reasons :

a. You are sure to hit a frequency where the ear is most sensitive ... no matter who is listening.

b. More importantly, human hearing acuity is _sharp_ for sinewaves "sweeping" in frequency. Much more so, than "stationary" frequencies. The reason is eons of fighting for survival, amid doppler-shifting sounds from predators.

So, we complicate the program a little, and let *2pi*fj* be a ramp that starts low and ends high (or vice-versa) over the duration of the program. Note : this does _not_ mean that jitter always ... or in fact, ever ... manifests as a "sinewave sweep". We are _choosing_ a sinewave sweep, due to hearing acuity, to establish a worst-case bound.

3. *Worst-case jitter amplitude*. That's what you guys are going to determine  if we're ever successful in creating files. Keep adjusting the amplitude of jitter, using 16kHz as the audio "carrier" and a swept sinewave as the jitter "modulator", until the jitter is heard no more.

And you can rest assured, that any jitter _below_ this amplitude level (in nanoseconds) can not be heard. That's the bound we're searching for. And you guys now have all the info you need to find it.

Class dismissed


----------



## gymrat2005 (Oct 4, 2009)

lycan said:


> hey guys, thanks for keeping this thread alive


 Yes, thanks! I'm not one to understand all of the math, but I am following the thread closely to see how this concept of jitter plays out in "theory" vs. "real world" scenarios.


----------



## audiguy (Jul 30, 2007)

subscribed. Not sure how I missed this, but I have some catching up to do.


----------



## bluTDI09 (Mar 3, 2010)

I was just perusing through this thread and have Matlab at my disposal, so I created a few non-jittered wav files that seem to play back correctly. I know that some have already been posted, but maybe these will make for a good sanity check?

I will do some jittered samples next... so far it seems to be straight forward.

Edit: they are only 5 seconds long.... if that is a problem, I can make 10 second ones easily. Also, I attached a quick plot of the signals sampled for the first 2 periods of the 1kHz signal.


----------



## highly (Jan 30, 2007)

bluTDI09-
Great job! Those look real good. Could you run a 10KHz and 15 KHz sine wave and have a close look at the plot? The problems I was experiencing showed up at high frequencies as an interference pattern overlayed on what should have been a clean signal. The result looked like a square wave that had been juxtaposed over the sine shape. With any luck Matlab takes care of the details that I was tripping over!


----------



## bluTDI09 (Mar 3, 2010)

Here is 10 periods of a 10kHz signal and a 15kHz signal sampled at 44.1kHz. As far as I can tell, it looks as it should...

One question though for the OP: in this analysis of jitter, and the construction of "unjittered" and "jittered" audio files, are we going to apply a reconstruction technique to the discretely sampled signal? As you can see from the graphs I have attached, a discretely sampled sine wave no longer looks like a smooth sine wave. I know that the sampling frequency is sufficient to reconstruct the original signal according to the Nyquist-Shannon theorem, but I am not sure whether the Matlab wavwrite function or highly's code attempts that. Any thoughts?


----------



## highly (Jan 30, 2007)

Yes, I also noticed that at higher frequencies that there were an insufficient number of samples to visually represent a smooth sine wave. I am ignorant as to reconstruction of the sine wave and how that might be accomplished. How would the visual representation differ from what we see here? Would the reconstruction algorithm attempt to interpolate the samples such that you achieve a sample at the peak and zero cross points, etc?
-T


----------



## lycan (Dec 20, 2009)

Guys ... don't worry about how a sampled high-frequency sinewave "looks". As long as you've got at least 2 samples in each period, Nyquist is satisfied and all is well 

It would "seem" that sampling a 16kHz signal at 44.1kHz "creates" something that doesn't "look" much like a sinewave  However, what you're "seeing" in the sampled-time domain is the presence of higher-frequency _images_ in the frequency domain. These _images_ are _higher_ in frequency than half the sampling rate (so, you can't hear them), and will be "removed" by the anti-imaging (aka reconstruction) filters in the DAC ... creating a pretty sinewave once again 

In short : the DAC reconstruction filter ... which is nothing more than a close-to-ideal lowpass filter at 22kHz ... will make the sampled sinewave look nice & pretty  You don't have to "create" this filter in software ... it already exists in the DAC hardware.

What your eyes can _see_, and what your ears can _hear_, are two _very_ different things.


----------



## MarkZ (Dec 5, 2005)

To add to that, you can upsample the waveform in matlab by doing FIR interpolation if you want to _see_ a nice sine wave. The information is present; the sample rate is high enough to prevent aliasing. It then just comes down to interpolating with a filter-based algorithm.


----------



## thehatedguy (May 4, 2007)

What about non oversampling DACs that have no filter?


----------



## MarkZ (Dec 5, 2005)

I've never heard of a DAC without a filter.


----------



## loddie (Jun 23, 2006)

What about practical applications for car audio? Will slaving (i.e. word clock) a transport (i.e. Eclipse ECD-510) to a DAC (i.e Motu Traveler) reduce audibility of jitter?
If you are using multiple DACs (i.e., two Motu Travelers), should a master clock of be used to sync the two or is it better to slave one DAC to the other?


----------



## kenikh (Jan 17, 2011)

"share it with the masses" bump


----------

