Specifying jitter like that is incomplete and doesn't tell you anything? I'm not sure you understand the J-Test either.
I'm only interested in that 1 meter connection from a few simple devices to my DAC. I certainly respect your work but it does not apply here.
The question becomes where down the scale in what matters for a large scale system stops being important. If the connection is fiber then we can look at single mode or multimode. As most of the links you are considering are plastic fiber that is high loss multimode. So the loss actually helps reduce jitter!
Bill, your mistake was not pinning down WHICH jitter he was measuring. Probably not at the clock pin.
What clock pin? The clock is recovered from the data stream. Making a clock with system needed very low noise or jitter is common place. That is not an issue.
Running the AES standard test. Dunn developed the J-test on his own and it has since been adopted. However what Bill showed did not specify if it was the original 24 bit J-test or the 16 bit version. Certainly makes a difference in interpreting the results.
Last edited:
Relying on measurements presented here of decent home audio gear I'm not worried about jitter.
As for the other point since they make Doppler flow meters I was interested in applying this to spectral spreading due to turbulent flow that would exist in almost any real listening space. I suspect the 20 psec level is readily exceeded. Since there are folks very interested in very low frequency random jitter effects, I though it would be interesting to put a limit on what could be measured in the actual free sound field.
The problem of frequency dependent attenuation etc. in a stadium or auditorium was not on my list.
Can you please share that with some of the people here - I mean SHOUT it out.
1985 was like still in the dark ages. We did have the 5534 I guess, so let's say it was the Renaissance.
There has never been a better time for music--digital or analog. I think I've said that in the past, and, if not, then let's make that clear. At least on the electronics side.
If there are better pressings now than ever before, I'm glad to hear it. I'm honestly ignorant as to the availability of good pressings because, well, it has been much easier for me to work on building up one form of media than two. And far less hardware intensive (although the ritual of a record player is very enjoyable).
I fear you're going to have a devil of a time with that measurement. Temperature gradients within a room are going to vary substantially, unless it's the basement bunker-type listening room. Even then, without a few ceiling fans for circulation, there will be noticeably hotter and colder regions. Probably worth profiling the temperature of a few places in your room first to give you an idea as to the magnitude of the problem.
Ah, Scott, 20 pS, let us see.... Any air movement in the room? Say forced air heating or cooling? Window open? Somebody breathing? At a 10' listening distance what air velocity do you think needs to exist between your ears and the loudspeaker to get say 1 uS?
In one of my stadium designs there was a bay on one side and a lake the other. Winds of typical 15 MPH would move the projected sound just a bit...varied from +/- 25 degrees. That would change the path length and transit time by 8 mS.
So in a room I would expect path length variations to be in uS. As this isn't perceived as an issue, my feel is that there are different perception mechanisms in play for jitter vs path distortion.
Whose digital receivers are you using? The current generation can get below 50 pS without help. Your seeing 100 to 1000 times this. Its hard to see how a PLL could have that much dynamic range, unless the master clock has issues, which seems really unlikely.
Using fiber optic to get sub picosecond timing accuracy is not trivial but there are published articles on how to do it since its needed for things like CERN.
Using fiber optic to get sub picosecond timing accuracy is not trivial but there are published articles on how to do it since its needed for things like CERN.
I had to run 31 pieces of 400 foot single mode for timing, they wanted timing stability in the 60 fs range IIRC. Had to pull them in their own partition in the tray, and it had to be away from the power conductors.
Seeing such high nsec jitter numbers being bandied about seems pretty high.
John
3,000' in a stadium sharing cable tray. Back then multi mode using the HP TTL to light and back modules. Looking at the data packets. The generation one newer than the AP I was using started doing the J test. System worked and is still in use.
One meter! Can't even get that close in a control room!
I've measured plenty of jitter. Normally on high speed interfaces, but 5ns is a lot for a properly engineered audio DAC subsystem, as per the example in the website quoted.
Last edited:
Do any of the audiophile companies use SOTA laser ROSA's and TOSA's like those in 40GB telecom? We set up a proof of concept HDMI link with a 10G telecom chipset but it never went anywhere. Also CERN, etc. do not use opto-isolators for SOTA data links.
Ah, there's the rub, we are talking about audio gear, not properly engineered stuff! (Or we aren't quite on the same page, looking at large complete systems rather than a single piece close up.)
SPDIF/AES standard has a problem with its imbedded clock that makes the clock recovery harder. The header doesn't follow the rest of the clock form and requires some magic to work around, but it seems that AKM and Wolfson have really good solutions. TI's is a bit long in the tooth but still not bad. its essentially a problem from 20 years ago that is solved. The AK4415 will reliably get less than 20 pS jitter from Toslink. In long runs more tricks may be required, especially if there is some significant dispersion in the link. Plastic fiber would not be ideal and neither would the red toslink transmitter-receiver. But there are plenty that will work. The ADI HDMI was a good demo, unfortunately there is essentially no market for long HDMI cables (maybe 5000 annually worldwide).
- Status
- Not open for further replies.