Random jitter causes noise (and possibly noise modulation). Signal-related jitter causes distortion. Both are very small unless jitter is large. It seems normal for people to want jitter specifications which are much better than can reasonably be achieved (especially for those not experienced in digital design and transmission) and also much smaller than can be heard. A good way to get high jitter is to take a very low jitter clock and just 'glue' it on to existing circuitry, yet this is what many audiophiles do.
Last edited:
We are studying to make a Spidif hardware that will be clocked after the IC...using high quality clocks and flipflops....so we are reasonable sure to achive 5-9ps of jitter on the output (coaxial and bnc). Most spidif solutions have 100ps of jitter on the output + optical connector jitter of 1.5ns. I am wondering if anyone thinks its a good idea to build such hardware with above specs
Hi Ioan,
Wouldn't any jitter be baked into the spdif (by the i2s -->spdif chip (WM8804 or AK4113 etc)) already... you can reclock the new overall spdif clock, but not the i2s encoded within it, can you, isn't it too late?
Jitter can never be introduced as long as a signal stays digital. The timing between two samples needs to be known by the decoder. Jitter can be buried into the signal itself and it happens in the ADC stage. Jitter on a s/pdif line is not "introducing" jitter to the signal, it is causing jitter at the point of digital word conversion to analog because the clock used, is extracted from the s/pdif link (nothing has happened to the digital words).
(The above is valid for a standard (old) drive / dac configuration. There are mechanisms to avoid jitter at conversion e.g. buffer/re-cklocking, PLL etc.)
//
(The above is valid for a standard (old) drive / dac configuration. There are mechanisms to avoid jitter at conversion e.g. buffer/re-cklocking, PLL etc.)
//
Last edited:
What re-clocking does is time align or set the signals being relocked to the time domain of the re-clocking signal. Re-clocking doesn't necessarily or inherently reduce jitter on the signals being re-clocked. Instead, jitter on the signals being re-clocked will be substituted for the jitter on the re-clocking signal. The difficulty is that it probably will not be a trivial endeavor to produce a re-clocking signal with less jitter than have the signals being re-clocked. That certainly will be true for a DAC utilizing S/PDIF signal recovery via an PLL based digital input receiver chip without benefit of some closed-loop (between DAC and data source) clock architecture.
Some early digital audio interfaces did just that. Sony used such an interface in the mid 1980s on their first generation DVTR.
While not obvious in the audiophile world, there are very good reasons for a single wire* serial AES standard such as broadcast plants. Consider where I work we have an AES matrix switcher that has 2048 inputs by 2432 outputs! Now if there was a separate clock line, that matrix would have to be twice as large. Then consider the timing skew nightmare!
SPDIF is not much unlike AES-1992 which is just a balanced signal at a higher voltage level 7-10vpp. Then there's AES-3 which is very similar to SPDIF except that AES-3 is 1 vpp on 75ohm coax where as SPDIF is 600mv IIRC.
There are also some minor bit stream differences between AES and SPDIF that can basically be ignored these days. They dealt with early copy protection on consumer DAT recorders but were never really implemented in practice.
I have taken AES-3 feeds directly into many consumer AV receivers SPDIF inputs via a simple BNC to RCA adapter for low cost production room monitoring and it works just fine. The receiver just has to support 48khz PCM which most do since DVD has been around.
*A balanced AES switcher still uses a single crosspoint layer. They just unbalance on input and re-balance on output just as with large analog switchers.
Last edited:
No encoding is different that jitter....we can take the encoded signal and realign with bclk (clean) or mclk (clean)
Everything will be done in FPGA with the realignment outside (a la Kali)
Yeah we think that jitter will be closer to 6ps than to 10.
Everything will be done in FPGA with the realignment outside (a la Kali)
Yeah we think that jitter will be closer to 6ps than to 10.
Even 100ps of jitter on an AES/SPDIF interface is like throwing paper clips out of WTC1 to delay the collapse!
When you deal with HDSDI streams at 3gbs, then we worry about single digit jitter on the ps range. But AES/SPDIF is much lower in frequency.
Do the math! Consider the length of an audio sample. Now displace that in time by 100ps. You think any human can detect that timing slip?
When you deal with HDSDI streams at 3gbs, then we worry about single digit jitter on the ps range. But AES/SPDIF is much lower in frequency.
Do the math! Consider the length of an audio sample. Now displace that in time by 100ps. You think any human can detect that timing slip?
Seems like slower signal would be the more sensitive one? Isn't the 100ps jitter on every single bit (or sample) essentially making them play at random times, relative to each other, slapping around +/- 100ps? Just tryin' to learn -- I do software IRL
Last edited:
Seems like slower signal would be the more sensitive one? Isn't the 100ps jitter on every single bit (or sample) essentially making them play at random times, relative to each other, slapping around +/- 100ps? Just tryin' to learn -- I do software IRL
It's all about the order of magnitude. This is where the audiophile community and the engineering community always fail to connect.
If I am fitting an exterior door on the space shuttle or a deep sea sub what are my tolerances for the door jamb?
Now do I need the same tolerances fitting a new door on your bedroom closet?
100ps of slop on a 48K-96K AES stream is irrelevant in the engineering world.
Some of these DAC charlatans love to show hand drawn scope pictures with a 1kc tone and the "nasty" jitter sidebands. But what you don't often see is the actual measured amplitude of those sidebands in the picture. If they are 140db down, how is anyone going to ever hear them?
What is the S/N of your power amplifier?
What is the NTC rating of your listening space?
Last edited:
Gusser, please forgive me if I misunderstand you here, but it sounds like you may be referring to the magnitude of jitter required to provoke actual bit errors. If so, this is a common misunderstanding of the audiophile's concern about jitter. Of course, over the short link lengths and low data rates involved in domestic digital audio application, any jitter great enough to provoke actual bit errors could only be due to something faulty in the link.
The audiophile's concern is rather over the effects of jitter at data domain conversion. The audibility of the resulting analog sidebands is controversial, even though they are at levels which at it would seem they should be pretty much inaudible. While broad band jitter floor can and usually is be quite low these days, there is still some debate about close-in sidebands. The really close-in sidebands appear more as a broadening of the center tone than as discrete spectral lines. As such, they could be much greater than the jitter floor without jumping out as such on a spectrum analyzer. Whether even high levels of really close-in jitter should be audible, those being the manifestation of Hertz and sub-Hertz phase noise, is also somewhat controversial.
Last edited:
No, I am beyond bit errors here. I understand the audiophile concern of sampling skew due to jitter. But again it's not a practical problem I ever found in competently designed gear.
Yes it is quite controversial.
I second that 200%.
See attached files : one is a €2000 HT receiver from a famous japanese brand ; the other is a cheap WM9905+ES9023 I put together. Both play SPDIF over TOSLINK from a €29.99 HYUNDAI CD-DVD-MP3 player. This player is a true piece of junk, the power supply is so wimpy the display dims when it seeks and its output jitter is truly humogous. A perfect source for this test. One graph is full range, the other one centered on the test frequency, sorry about that...
...and the last one is WCLK coming out of WM8805 with a nice implementation mistake on my part
Brownie points if you figure which is which without looking at the plot legend.
Attachments
...and the last one is WCLK coming out of WM8805 with a nice implementation mistake on my part
I noted an unusual J-Test frequency of 35Hz. Aren't those usually performed at 1/4Fs?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.