|
Computer Audio Asylum Music servers and other computer based digital audio technologies. |
|
|
|
Computer Audio Asylum Music servers and other computer based digital audio technologies. |
|
In Reply to: RE: JPlay and CPlay = garbage - Or posted by fmak on February 11, 2012 at 22:14:16:
"it is the computer's fault for producing jitter and destroying waveform integrity."
The data can always be reclocked so long as the jitter is not extreme. There is no basis for ascribing "fault" to a computer. It is a data moving device and as long as there is sufficient signal integrity that the data can be decoded the computer has done its job. Since the time between bit transitions on SPDIF is many ten's of nanoseconds there is no problem decoding signals with several nanoseconds of jitter. Looking at an eye pattern, the eye has to be clearly open, but it does not have to be anywhere near perfect. By contrast, the master clock in the DAC must have jitter below 10 picoseconds for full 24 bit accuracy. Given that a perfect signal created at the computer with zero jitter may still have several nanoseconds of jitter when it arrives at the DAC, it is absurd to place the blame on the computer for small amounts of jitter. The DAC will have to have excellent jitter rejection in any event so as to deal with the effects of the cable. If a DAC lacks this degree of jitter reduction then one can put a reclocker between the computer and the DAC. This is a band-aid in that the DAC will still have to deal with jitter introduced on the cable from the reclocker. Given that it is physically impossible to remove the jitter problem from the domain of the DAC, if "fault" is to be allocated, the fault must lie with the DAC.
With the typical SPDIF configurations, the DAC gets its clock from the computer, and thus it has to use a PLL or some other means to clean the clock. This is a poor architecture. Instead, if the clock starts at the DAC and goes in the opposite direction then there won't be any need for PLLs to clean the received clock. The DAC can work off its own clean local clock that has never had to traverse any noisy cables with limited bandwidth. If you use the juli@ with external clock you can slave the computer to the DAC and put the DAC in internal mode. Unfortunately, there may be two problems with this: (1) It will be a pain in the ass whenever the DAC sampling rate must change. Since the clock starts at the DAC some means will be needed to put the DAC at the proper speed. (2) most DACs are designed to work in both internal and external mode and may have designed their clocking to use common circuitry for both modes rather than have a separate clock circuit for each mode. I don't know how your various DACs deal with this problem when running on internal clock, but I do know that many proaudio DACs do not use a separate clean signal path for clock when running in internal clock mode.
The advantage of the async USB method is that it avoids the extra cabling of reverse clocking while still allowing the DAC designer to use a fixed master clock. In addition, the USB protocol allow the computer to tell the DAC the correct sample rate. Thus an async USB only DAC can avoid both pitfalls mentioned above. The unfortunate downside, however, is the baroque USB protocol. There will be a lot of digital logic inside the DAC that can interfere with noise critical circuitry, much more circuitry than needed for an SPDIF based DAC.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
This post is made possible by the generous support of people like you and our sponsors:
Follow Ups
- It there is to be "fault" it must be at the DAC - Tony Lauck 10:00:57 02/12/12 (3)
- This is - fmak 06:20:18 02/13/12 (0)
- Yeah, its the DAC - Scrith 10:38:11 02/12/12 (1)
- RE: Yeah, its the DAC - Tony Lauck 12:38:57 02/12/12 (0)
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
