[
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2008, Audio Asylum, all rights reserved ]
[ General ] [ Speakers ] [ Tubes ] [ Vinyl ] [ Digital ] [ Hi-Rez ] [ Video Asylum ] [ Cables ] [ Tweaks/DIY ] [ Music ] [ Films ]
|
Home
/ FAQ
/ News Classifieds / Events |
Audio Asylum Thread Printer |
Get a view of an entire thread on one page |
196.11.134.77
In Reply to: RE: Jitter Research, Analysis & Measurement posted by cics on March 24, 2008 at 12:55:55
I wanted to measure the setup with Scarlatti DAC as master and RME as slave. Clock connection from DAC's clock out is made to RME. Clock operates at 44.1k. Test wav file at 14kHz 24/88.2 is used.
Spectral analysis is very similar with 2kHz jitter sidebands having ~0.5db increase in level. This corresponds to Jpp of 76ps.
Setting DAC to slave mode gives Jpp of 72ps.
One more reason I don't think your measures are that reliable is that you don't measure the analog outputs of the DAC directly; instead they go through an A/D process performed by the ESI card and then you compare the file played with the one resulted by recording the analog outs of the DAC (at least this is how I understood your measuring technique to be).
So you don't have a way to quantify the jitter at the analog outs of the DAC because there is also jitter from the A/D process performed by the soundcard.
Something like this I think will give much more accurate results if you are that hardcore in jitter measurements:
http://www.tek.com/products/oscilloscopes/dsa8200/ (20K US$)
http://www.tek.com/Measurement/applications/serial_data/jitter.html
http://www.tek.com/Measurement/applications/serial_data/jitter/recommended_test.html
That's how DSOs work. Unfortunately, my Elab-80 won't do (only 8 bit resolution). Yes those high tech versions will yield more accurate results (which would show a lower jitter measure). There's no need to compare to input file - you need to analyze the analogue output (which goes through an ADC).
If the ADC introduced substantial jitter when recording the analogue outputs, this jitter would be clearly visible in the spectrum analysis. In fact what is shown is inclusive of the ADC's jitter distortion (which gets added to analogue waveform from DAC's output). This means the result shown is a high water mark - a DSO without jitter would show even less jitter in the recorded output!
Even with an ADC step that's not jitter free, Jpp of 72ps and 76ps (with DAC as master) remain valid measures. Making assumptions over the jitter introduced by the ADC and thus reducing the Jpp figure is not my preference. Its like attributing all the good things to the DAC & Transport and parking the 'not so good' with the Recorder.
Your analysis that the ADC and DAC jitter are additive depends upon the assumption that the ADC and DAC sample clocks are independent. If they are not then the situation is complicated and the possibility of cancellation can not be easily excluded. Murphy's Law of Clocks: A multi-clock system requiring synchronization will have unsynchronized clocks, while a multi-clock system requiring unsynchronized clocks will have synchronized clocks.
Unintended synchronization of clocks was first observed by Huygens in 1673. More recently, it has been a factor in computer networks, where I have personal experience with the phenomenon and how it can impact performance as well as measurement accuracy.
Tony Lauck
"Perception, inference and authority are the valid sources of knowledge" - P.R. Sarkar
ADC clock is independent from DAC clock. DAC recovers clock from SPDIF input whilst ADC utilizes it own XO. Measurement is not in digital domain, i.e. input signal gets converted to analogue which in turn gets recorded.
Yes the situation gets complicated if clocks have dependency - this arises when working entirely in the digital domain such as computer networks.
Given that the two clocks are controlled as you described, there is no engineered reason for them to be synchronized. However, if there is any means of coupling energy associated with one clock into the other clock and if the free running rates of the two clocks are sufficiently close, then it is possible for the two oscillators to become synchronized. This happens in many systems of coupled non-linear oscillators. (A Google search turned up one such example.) In one case that I observed with computer networks, the separate clocks were "independent" crystal oscillators that were intended to be oscillating separately. Their synchronization was an artifact of the circuitry, not something intended by the digital design.
Since you are measuring to limits of precision that are close to the limits of your equipment, then I think it advisable to conduct some tests to ascertain that your "independent" clocks are actually independent. I would consider this to be part of the calibration procedure for your test setup.
Tony Lauck
"Perception, inference and authority are the valid sources of knowledge" - P.R. Sarkar
What would the result be of such XO synchronization?
I'm looking into reapplying optimizations that I reversed for the cMP recorder (to accommodate Cubase LE). The 2kHz jitter component I suspect relates to the ADC and nothing else.
Based on optimizations I've reapplied, there's an even better spectrum (using 14kHz tone). This seems to rule out synchronization of XOs?
What would the result be of such XO synchronization?
Without knowing the details of the circuitry involved I don't believe that it would be possible for anyone to answer your question. I think it would depend very much on the details of the circuitry and the causes of jitter in the two XOs, which would be things on the margin of the original circuit designs. In any event, if it were an obscure circuit design problem, it would be beyond my expertise, as I am a systems person and not a circuit designer.
However, I can take a guess. If the two clocks are synchronized then it becomes possible to consider that some amount of their jitter is correlated. The effect of this correlated jitter could then cancel to the first order. But if the clocks are not synchronized, then the correlated jitter would sometimes be additive and sometimes subtractive and how this appeared in the final results would depend on the method of averaging and the beat frequency between the two sample clocks. If there is no correlated jitter then I don't think it would make any difference whether or not the clocks were synchronized.
You can test for clock synchronization by measuring the relative timing accuracy of the two systems using a recording with two impulses separated by several minutes of silence. If the clocks are not synchronized, you will be able to determine the beat frequency of the sample clocks, which may be something to take into consideration in doing your averaging.
I will think about this some more and if I come up with something I will send you a private email.
Tony Lauck
"Perception, inference and authority are the valid sources of knowledge" - P.R. Sarkar
I'm curios if you would get the same results by repeating the measurements a few more times. My guess would be that they would vary because the numbers you obtained can't be an absolute unchangeable value.
My point was not to reduce the Jpp value because of the jitter introduced in the A/D process. What I think is that without you knowing exactly what amount of jitter imparted the ESI card in each measurement instance you can't treat the results you've got as absolute values, especially when the difference is just 4ps.
You didn't say how it sounded with the DAC as Master. Did you listen to it in this way or just made the measurements?
I'm curios if you would get the same results by repeating the measurements a few more times. My guess would be that they would vary because the numbers you obtained can't be an absolute unchangeable value.
Measurements were repeated and over separate days. Even at 24/88.2, I got to same 72ps. Likewise, on DAC master setup, measurements were same at 76ps.
A 4ps difference is 5.6% worse - that's material in a game where everything counts.
You didn't say how it sounded with the DAC as Master. Did you listen to it in this way or just made the measurements?
Same as before.
Did you made all the necessary modifications in the control software of the RME to put it on Slave?
Also, did you terminate to 75 Ohm the WC input on the RME? In the manual it says that the WC input is not terminated:
"When shipped, the word clock input is not terminated. Termination with 75 Ohm is available via jumper X105 on the Expansion Board.
The HDSP 9652’s word clock input can be high-impedance or terminated internally, ensuring maximum flexibility. If termination is necessary (e.g. because HDSP 9652 is the last device in the chain), bring jumper X105 on the Expansion Board into position 75 Ohm."
If properly setup it is very unlikely for the DAC to have more jitter when clocked internally than when it receives the clock from the soundcard. Did you repeat the measurements to see if they are consistent?
Did you made all the necessary modifications in the control software of the RME to put it on Slave?
Yes.
Also, did you terminate to 75 Ohm the WC input on the RME?
Yes.
Other points:
When I measure with RME as master, Clock card is disconnected from main PCI card. It's not good enough to just disconnect the BNC cable.
You cannot have both dCS and RME as Master - you hear abnormal click sounds.
- RE: RME setup - Sunya 01:24:40 04/01/08 (8)
In Reply to: RE: RME setup posted by cics on April 01, 2008 at 01:16:59
What do you mean the Clock card is disconnected? If it's disconnected how can the RME be still the Master? The Clock card has both WC Out and WC In so, whether the RME is Master or Slave, the Clock card should always be connected.
To set DAC as master, the sync button is pressed which causes the DAC to switch from slave to master. In master mode, it either syncs to the clock input signal (if present) OR its own internal clock.
What you're suggesting (I think) is to set RME as master AND DAC as master. A cable is then connected to RME's clock out and to DAC's clock in. Having two masters is not something I would try.
No. You said that when you set the RME as Master and DAC as Slave you didn't also use the Word Clock Out of the daughter card (because you disconnected it) to slave the DAC. You used a simple S/PDIF out signal and the DAC had to extract the clock from this signal instead of receiving an Word Clock from the RME to its Word Clock input.
Also, if the DAC is set to Master how can it sync to an external clock input? If it syncs to an external clock signal it is not the Master anymore. A digital device is Master when it syncs to its internal clock only.
Also, if the DAC is set to Master how can it sync to an external clock input? If it syncs to an external clock signal it is not the Master anymore. A digital device is Master when it syncs to its internal clock only.
This is specific to dCS. As far as I know there are no standards defined. For Scarlatti DAC, the sync button has 2 'master' options: WClk (external master clock) & Master (internal master clock). The remaining option is called Audio (for slave).
I see... The first "master" option, WClk, is just the name for slaving the DAC to an external Master Clock, so technically the DAC is not the Master, it's just slaved to an external Master Clock.
This embedded clock is then recovered by DAC's receiver chip.
Why didn't you use the Word Clock Out of the RME when set to Master? At least this way the clock would not be embedded in the SPDIF signal...It doesn't make any sense for the DAC to have lower jitter when it has to extract the clock from an SPDIF signal than being directly controlled by its internal oscillator.
That configuration won't work. DAC as slave recovers clock from SPDIF. Other clock connections are not used.
Then how did it work with the Scaralatti Master Clock? How does it matter if the DAC receives the clock from the external Master Clock or from the RME card through the same BNC connector? Is it because the file played is upsampled at 88.2 or 96 and the Word Clock input will not accept these sample rates?
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2008, Audio Asylum, all rights reserved ]