|
Digital Drive Upsamplers, DACs, jitter, shakes and analogue withdrawals, this is it. |
|
|
|
Digital Drive Upsamplers, DACs, jitter, shakes and analogue withdrawals, this is it. |
|
In Reply to: Hmm.. What were the results of DR1394 tests on capturing 1394 bitstream? posted by yura_POL on May 21, 2003 at 07:24:05:
The good Dr. claim to be an engineer who is working at a semiconductor company developing 1394 equipment, and that he has a test bed where he can capture 44.1/16 PCM bitstreams directly from a Pioneer DV-47Ai(same model as DV-S755Ai) 1394 link.He completed some tests that he and I agreed upon. Test disc was CCR Cosmo Factory, CD layer of the SACD. Test track was track 9, Who'll Stop the Rain.
He made 3 captures from the 1394 link of the DV-47ai:
1) From the stop state, hit button 9 on the remote. Capture 8
megabytes or about 47 seconds of bitstream.2) From the stop state, hit button 9 on the remote, then wait
11 seconds and hit track repeat.3) From the stop state, hit button 8 and let this track play.
Then start capture at the last 7 seconds of track 8 and the
first 40 seconds of track 9.Results:
Same bits every time.
His contention is that if his "fc /b" program in a DOS window is showing that the same bits are delivered for each iteration in a captured bitream data, the bitstream was exactly the same each time, irregardless of how the tracks were being sequenced, then for all intend and purposes, it would be jitter free and there should be no audible differences.
That still doesn't explain why I am still hearing the problem in the Pioneer combo though.
Did this guy just measured the wrong things perhaps?
Frankly, the measurements he had made did not surprise me. Jitter does not usually change the data. It only corrupts the clock or timing of the data. So it will not show up on absolute measurements of bits. He would need to do a specific jitter measurement or capture the data stream (and clock) on a digital oscilloscope, for example.
The timing information must be viewed. The reason jitter causes sonic problems is not because of changed data. It is because DACs can be negatively affected by jitter, causing compromised performance or data CONVERSION errors. A DAC's analog output can be degraded by jitter in terms of added noise, distortion or in extreme cases, conversion errors.
If we were to repeat the measurements using a high speed digital storage oscilloscope and compare the amplitude versus time data (waveform), we might see differences. Note this is the same way an analog signal is being measured, just much, much faster. If the differences in the waveforms are significant, you will get differing sound out of the DAC. Bit for bit measurements would show only huge data errors, unlikely to be caused by jitter.
Regarding 1394. Some designers like Ed Meitner have decided against using it for several reasons:
1. the clock is integrated within the data stream and is NOT discrete;
2. recovering the signal and clock from 1394 is a VERY difficult and complicated process where there is ample opportunity to screw it up
If digital transmission to the DAC uses an embedded clock the only way to deal with the Jitter issue would be to throw away the clock and re-clock the data using a newly generated clock signal. Then there are also some other protocol in the pipeline like the Super-MAC, which is said to be superior in every way over 1394, and a whole lot simpler.
Within a couple years, HDMI will probably replace 1394 anyway. But that's probably worse and we'll still have to content with the jitter issue as the audio, timecode plus video data will be meshed through one single cable.
This post is made possible by the generous support of people like you and our sponsors:
Follow Ups
- Results of DR1394 tests on capturing 1394 bitstream - jeromelang 20:40:02 05/21/03 (0)
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2024, Audio Asylum, all rights reserved ]
