 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
198.54.202.234
Jitter Research, Analysis & Measurement Abstract
Sound is better with the cMP (configured as Transport) and acting as Master. Conventional wisdom suggests a Transport slaved to a DAC is best. I held this view until now. Using the dCS Scarlatti Clock and trying many things (power cords, conditioners, high-end BNC cables) it failed to impress. A measurable way of understanding this apart from subjective listening is covered.
Background
Why cMP sending SRC (Secret Rabbit Code) upsampled 24/96 SPDIF via toslink is superior led to this work. Transports providing an (embedded) master or sample clock are meant to be inferior (as clock recovery is performed by a receiver chip). My subjective listening tests shows otherwise.
The asset test for great sound is whether I can listen to an entire CD (that I enjoy and am very familiar with) without feeling tired and uninvolved. Things like blind testing and focus groups don’t help much here. Alternatively, pretending things sound better (placebo stuff) is short-lived because as you make your way through an entire CD, reality sets in… Here are the results for the different setups:
- cMP with RME HDSP 9652 slaved, Scarlatti Clock set for ‘No Dither’, DAC is AA Prestige SE. Sound is unpleasant with harsh / bright elements. There’s no way I could listen to an entire CD. Stop.
- As 1 above but Scarlatti Clock set to ‘Dither’. Dithering helps exercise PLLs. A significant improvement over previous but still some subtle digital artifacts – spotlighting of high frequency content. Initial few seconds sounds nice but as you work your way through a track it starts wearing you down. HF spotlighting is fatiguing and a full CD listen is a stretch. Pause.
- No Scarlatti Clock (RME set as Master), cMP > AA Prestige SE. cMP acts as master. No more spotlighting with a natural overall sound (treble is sweet and elegant). Play.
- Repeat first 3 with dCS Scarlatti DAC. Same results. Scarlatti DAC makes for an improved sound over AA. Both exceptionally good.
- cMP Transport & Scarlatti DAC slaved to Scarlatti Clock. This is how dCS expects the Scarlatti Clock to be used. Sound is very similar to 2, HF spotlighting! Listening to a CD is difficult with 3 still rendering a more natural sound.
- cMP > Scarlatti DAC with Scarlatti Clock completely disconnected. This betters 3 - pure galvanic isolation is achieved (using toslink). RME and dCS suggest clock input implementations are galvanically isolated. (I’d like to see the physics of how this is achieved as my understanding of quantum physics suggests this to be impossible).
These tests were done using the E2140 processor. By upgrading to the E1200 processor, scenario 6 has lifted to a better level. Aside: switching to the Juli@ soundcard is equally impressive and it’s been tough making a call against the RME. Only after the E1200 upgrade, the RME soundcard performed better.
Of all things important in a system, natural bloom is by far the most important. Jitter (and incorrect upsampling) bedevils this – this is not artificial bloom which becomes apparent in a while and is fatiguing. Instead, the bloom being referred to is un-hyped and slightly understated but never fatiguing. This leads to sound that’s very lifelike and exhibits a real presence.
Computers superiority in jitter performance is not well understood. Consider this: SATA specifications demand strict jitter tolerances for which standards are defined (something like not exceeding 160ps peak). Computer manufacturers utilize jitter testing equipment measuring in femto seconds (a femto is a thousand fold less than a ps)! This is all very necessary to achieve very high bandwidths and extremely low bit error ratios.
Jitter Research
The late Julian Dunn laid the foundations for understanding jitter. His work is most impressive and can be found on the web. Jitter refers to timing errors of the master clock used in DACs and ADCs. The slightest errors in timing causes signal amplitude errors. Its effects can be modeled, simulated and measured.
Jitter is Random or Deterministic. Whilst random is easy to understand, deterministic jitter is not. There are 2 forms: data correlated and periodic. Data correlated refers to jitter arising when certain patterns of data is present. Periodic is cyclical and has a defined frequency. Over a single period (1/frequency), clock signals stretch then shrink but total time over the period remains accurate!
Random Jitter
Random Jitter impacts the DACs SNR. This is also modeled and as one would expect, for excellent SNR performance, random jitter must be low. Improvement in SNR is slow as large reductions in jitter are needed.
Another important ingredient is the sampling frequency. Higher the Fs, better the SNR. Each doubling of Fs results in ~3db improvement in SNR. This is inferred from Burr Brown’s very conservative formula for calculating DAC SNR.
Periodic Jitter
Periodic Jitter has a defined frequency and its distortion can be modeled. DACs (and ADCs) cause distortion (sideband noise) when subject to periodic jitter. For a given fundamental input frequency, the fundamental together with side bands (distortion) occur on either side (distanced by the jitter frequency). An example can be seen in figure 1.
Figure 1. Periodic jitter of 7ns (Jpp) at 3kHz for an actual 10kHz pure input tone. Sidebands of 7 & 13kHz occur and its distance from the fundamental is given by the jitter frequency (3kHz). Source: Audio Precision, “Measurement Techniques for Digital Audio” by Julian Dunn. Quote: “In this figure there are also “skirts” to the spectrum closer to the 10 kHz component. These are due to some low-frequency noise-like jitter in the system”.
Figure 1 shows sine wave periodic jitter affecting a 10kHz audio tone. Square wave jitter is more harmful giving rise to continuous sidebands throughout the audio band. The strength of these sidebands is determined using Dunn’s formula:
Figure 2. Sideband energy levels increase with higher audio frequencies and higher jitter levels (J as in Jpp). Note wi refers to: F (input audio frequency) 2 Pi. (This is called the angular frequency). For example, Jpp at 7ns acting on an input tone of 10 kHz gives sidebands at -79.2db (as in figure 1).
In simple English, this says the higher the input frequency and with increasing jitter (Jpp), the greater the strength (or energy) of the sideband distortions. Periodic jitter is more offensive than random jitter as its sidebands are aharmonic. Music is harmonic (extending into high frequencies) and when such jitter is present, much of the natural tone decay is polluted. Natural bloom is lost. Jitter does most damage in the higher frequencies, ie. when large voltage swings occur (called slewing) as this results in much greater signal amplitude errors.
Jitter Accumulates
There’s more to jitter than just Random and Periodic, for example:
- Interface jitter (transmission related timing errors – explaining why digital cables sound different),
- Data correlated jitter (jitter arising when certain patterns of data is present),
- Intrinsic jitter of receiver chips (that decode incoming SPDIF or AES digital signals).
These all affect audio quality (and potentially cause sync lock issues). What matters is that jitter is accumulative. This means all jitter sources combine in sometimes very harmful ways causing jitter gain (increase in Jpp).
Ultimately, all this jitter collectively affects the sample clock at the DAC or ADC chip. It’s at this sample clock level where signal conversion occurs that distortion arises (signal amplitude errors).
Clock jitter at the sample clock (LRCK) is most detrimental to DACs (and ADCs). DAC chips utilize multiple clock signals. Here’s AKM’s AK4358VQ (as used on the Juli@ soundcard).
Figure 3. Pin layout of AKM DAC chip that offers 8 output channels (4 LR pairs), digital data input (at bit level) is from pins 13-16. Clock pins are 17 (LRCK), 10 (MCLK) & 9 (BICK). AKM calls MCLK the Master Clock which is synchronized to LRCK (the most important and often referred to as sample or word clock). AKM uses MCLK to operate its interpolation filter and delta/sigma modulator. Ignore DSD pins.
Figure 4. Clock signals (PCM default mode) for AKM DAC chip. LRCK (sample clock) where 1 cycle is 1/Fs. BICK is the bit level clock similar to an SPDIF signal, for 24/96 BICK operates at 6.144mHz.
The sample clock determines when the sample (left and right pair) is dispatched at the desired voltage level for that specific moment in time. Timing errors here results in signal amplitudes out of time. Thus at the actual intended timing point, we have signal amplitude error. This is jitter distortion.
What’s very important to understand is that jitter is rarely random, it’s almost always periodic, ie. the worst kind. Phase Locked Loops (PLLs) are excellent at removing such periodic jitter. No matter the system configuration (i.e. single box, transport/dac, etc.) PLLs are hard at work removing jitter. Unfortunately, PLLs only do so after a defined ‘cut-off’ frequency which is often 1kHz. Any jitter below this cut-off frequency is not removed. One could argue that designs should move towards shifting jitter energy to high frequencies thus PLLs at the DAC’s sample clock effectively removes jitter. Unfortunately, such high frequency jitter comes with aliases and images of its own that occurs well below the cut-off.
Jittter Analysis
Jitter is almost always periodic in occurrence. Fortunately, for a given input tone (pure sine wave), this type of jitter can be modeled. But first, it’s important to understand what exactly periodic jitter is. The best way is to think of a tiny virtual clock oscillator beavering away at the DAC’s sample clock. This tiny oscillator is constantly changing the sample clocks timing accuracy (phase or edge error) – the actual clock phase is shifted by a small amount in time (ie. jitter error). This jitter error is given by:J(t) = 0.5 Jpp Sin( Jf 2 Pi t)
Where:
J is jitter error in seconds applied to the sample clock phase,
t is the actual time for the clock phase,
Jpp is the peak to peak jitter,
Jf is the jitter frequency, and
Pi is the mathematical constant 3.141593…
In simple English, this formula says, the sample clock jitter (or phase error) is cyclical and at its worst would be half of Jpp (either adding to or subtracting from the clock phase). Over a full jitter cycle, the sample clock maintains perfect accuracy, ie. there are clock phases where the clock signal takes longer followed by shorter intervals. This is the nature of the Sin math function. Thus:
- Given Jpp and Jf, we can determine the sample clock timing error for any sampling period (1/Fs).
- For a given input sine wave tone, each sample’s signal amplitude (for any Fs) can be calculated.
- Jitter distortion (erroneous signal amplitude) can also be calculated. At sample time t, the signal amplitude is what it should have been less the timing error. That is: v’(t) = v(t – J(t)), where v’ is the distorted signal amplitude.
Dunn provides the mathematical formula for modeling this jitter distortion of given Jpp and Jf when applied to an input sine wave tone. A utility, cicsTone is used to generate a wav file that implements this formula. cicsTone provides both pure tones (at either 16 or 24 bits at any Fs) and tones afflicted with periodic jitter. Very basic dithering and 3rd order noise shaping is applied – nothing sophisticated here at all. cicsTone will be available as usual in source and executable format at SourceForge.
Here’s a spectrum view of a 24/96 10kHz generated tone with jitter modeled at 7ns / 3kHz:
Figure 5. Compare this to figure 1 which is an actual live 10kHz tone having the same jitter. The model prediction is perfect with sidebands 3kHz apart (7 & 13 kHz) and of similar levels. Note frequency is in log scale. Spectrum is viewed using RMAA spectrum analyzer with FFT resolution of 0.37Hz.
This means that by recording the analogue outputs of the DAC for a given tone, jitter artifacts can be determined. The level & distance of the sidebands will provide exact Jpp and Jf measures for the Transport and DAC combination! Jf is taken from the spectral view whilst Jpp is calculated from the sideband level and using the formula in figure 2 (ie. solve for Jpp).
Using cicsTone, 3 generated test wav files are used:
Figure 6. Generated 24/96 wav files for measuring jitter. From left: 7kHz, 3kHz and 14kHz with simulated jitter at 7ns / 3kHz. The 14kHz test is to see the 3 tones (11, 14 & 17kHz) being recreated at the DAC’s output, ie. if this excessive jitter distortion was introduced by the ADC, it must be visible at the DAC’s output.
This type of analysis provides insights into the total jitter for both Transport and DAC. Things like the effectiveness of the DAC’s ability to reject incoming jitter (from Transport’s digital signal), complexities of interface jitter (and the use of high quality glass fibre toslink) and so forth is given by this overall measure. The need for Eye diagram analysis and other clock signal analyzing methods are done away with.
Jitter Measurement
cMP as Transport using RME’s HDSP 9652 soundcard feeding (24/96 via glass fibre toslink) to dCS Scarlatti DAC is measured. cMP provides master clock to DAC, ie. DAC is slaved to Transport.
Analogue outputs are recorded using a second cMP with some optimizations removed to cater for Steinberg’s Cubase LE recording software. Soundcard is ESI’s Juli@. The recording cMP also enjoys high quality power supply together with quality power cord and line filtration. Scarlatti’s balanced outputs are connected with high quality low capacitance interconnects at 25pF (Sommer Cable). XLR output from DAC connects to Juli@’s TRS analogue inputs. Cubase is set for recording stereo at 24/96.
This cMP recorder as a DSO offers 24 bit resolution with 384kHz bandwidth – for perfect measurements, high resolution with very high bandwidth DSOs are best.
Testing included the analogue outputs of a normal computer (Realtek ALC888 offering SNR of 97db), the recording cMP proved to be brilliant – showing all kinds of artifacts and noise. This was expected given that the normal computer is setup for high performance and not audio.
The recorded output from Scarlatti’s DAC using the 7kHz test tone is shown in figures 7 & 8.
Figure 7. Scarlatti DAC analogue outputs. Overall noise floor is at ~-136db with harmonics of the 7kHz fundamental at 14, 21, 28 & 35kHz. Noise in lower frequency bands (to just over 3kHz) is due to Scarlatti’s filter (set to filter 3).
Figure 8. Same as figure 7 but Scarlatti DAC filter set to filter 2 – preferred setting (although with some CDs, filter 3 is preferred). Note filter artifacts now move to the higher frequency band between 16 &18kHz). Same harmonics are visible. Noise floor drops to below -140db! THD is same at ~0.00039%.
What is cleanly seen from figures 7 & 8 after accounting for harmonic distortion and filter artifacts is the jitter component. For the 7kHz input tone, jitter sidebands are visible at exactly 2kHz away from the fundamental and correspond to a level of -122db. This gives a Jf of 2kHz and Jpp of just ~72ps!
Figure 9. Jitter is consistent with that seen in figures 7 & 8 with exactly 2kHz sidebands from fundamental. For 3kHz tone, sideband level is at -129db (1 & 5kHz). For 14kHz, same sidebands (seen between input side tones of 11 & 17kHz) are at -116db (12 & 16kHz). These levels correspond to the same Jpp of ~72ps. Remember, jitter sideband levels increase as input frequency increases. Recorded distortion is recreated at the DAC’s ouput (14kHz view showing 11 & 17kHz).
Both 3kHz (pure) & 14kHz (with side tones of 11 & 17kHz) resulted with exactly the same Jpp measurements (figure 9). This consistency is important to confirm such excellent jitter performance.
Conclusion
The greatest insight from this research and measurement is that jitter problems cannot be resolved by ‘polishing’ the sample clock. Clock polishing is treating the symptom and not the underlying cause. There’s no doubt the Scarlatti Clock offers amazing clock accuracy and low jitter. But XOs are achieving great levels of performance (ito accuracy and more importantly, low jitter ~20ps). Other factors like power supply noise act to destabilize XOs and consequently result in very poor jitter performance. A traditional transport based on spinning CDs will act to drastically destabilize the clock – in such cases, clock treatments as advocated by dCS are needed. This however does not hold true for Computer Transports.
What matters in design are the underlying causes. Power supply is well known and has seen amazing treatments. There’s much more. Figure 3 shows a typical DAC chip (this also holds true for proprietary DACs as similar inputs are required to perform its function). The seemingly perfect sample clock (after exhaustive treatment) entering the DAC chip would still be subject to noise ‘riding’ on other inputs. At a microscopic level, DAC chips are complex integrated circuits. The sample clock signal is NOT galvanically isolated. Hence noise pollution from data pins and other clock pins will no doubt impact negatively on the sample clock causing jitter. With DACs becoming ever more complex with even larger levels of sample buffering, this type of contamination is certain to grow. In other words, all pins need polishing. In a Computer Transport, things like RAM settings, its quality, mobo traffic etc. make a difference. The purity with which samples are streamed to the DAC is a big deal. This is where cMP excels.
From listening experience, jitter seemed very low. Never did I think Jpp of 72ps had been achieved! It makes perfect sense why the Scarlatti Clock failed to impress. The added complexity by way of an extra power supply, clock sync circuitry and loss of galvanic isolation adds more noise that eventually makes its way to the DAC’s sample clock. On the other hand, the Scarlatti DAC certainly impresses.
Follow Ups:
The 2 kHz jitter component was too coincidental. It relates to a software function on the cMP Recorder that operates at 2000 transactions per second (i.e. 2kHz). This is Juli@’s Mixer software which seems to induce jitter through digital logic. I decided to reapply all optimizations (esp. given that Cubase was launched using Explorer – the worst way to run Cubase).
Only 2 optimizations could not be done: E1200 processor and Minlogon (Cubase fails to start). A dummy wav file is used for which cMP’s software is set to start Cubase. Cubase allows for both Svchost and Lsass to be suspended. Thread optimizations is best left to Cubase.
With the recorder enjoying these optimizations, there’s marked improvement in measurements. Here’s the output for a 7kHz (filter 2) test tone.
Figure 10. dCS Scarlatti analogue outputs for 7kHz input sine wave. Filter 2. Harmonic distortion and filter artifacts are visible.
Figure 10 reveals no jitter components (including the previous 2kHz component)! Jitter no doubt exists but is buried in the noise floor. Sideband noise increases with increasing input frequencies. A test using 14kHz is more useful at revealing the jitter.
Figure 11. dCS Scarlatti analogue outputs for 14kHz input sine wave. Filters 2 (top) and 3 (bottom).
At 14kHz (figure 11), jitter artifacts become visible. The 2 kHz component is at a much lower level of -135.5db yielding Jpp of just 11ps. Other jitter artifacts at higher levels are visible. Here’s a zoom in picture for the 14kHz output (filter 2).
Figure 12. Zoom in: dCS Scarlatti analogue outputs for 14kHz (filter 2).
Any single jitter component over -130db would yield jitter at 20ps. No such levels exist!
These are the individual jitter components:
- At 2kHz, -135.5db Jpp 11ps
- At 1.605kHz, -132.0db Jpp 16ps
- At 5.904kHz, -134.0db Jpp 13ps
- Jitter like noise close to fundamental (600-800Hz, right channel only), peak at -131.5db Jpp 17ps (actuals: -131.5 17ps, -133.0 14ps, -134.7 12ps, -131.8 16ps, -133.5 14ps x 6)
This yields an overall Jpp of 51ps (RSS) .
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?
Great information! Your insanity will bring you great fame and recognition as one of the primer audio researchers. Your work makes for a case to bring Audio into Universities as a field of study. Dr. Cics my hat is off to you...
I'm just learning from the great people here at AA, Julian Dunn and others. Dunn's work is truly profound and I would be very surprised if its not covered in depth at universities.
Besides, its a great deal of fun!
Once we can deliver data to a DAC asynchronously, thereby removing clocks related to the source from the equation.
.
No, I mean a DAC that essentially treats the computer like a hard drive or network server. It buffers the data locally (e.g. 10 seconds of audio data), asking for chunks (e.g. 2 seconds of audio data) when the buffer is getting low (e.g. only 8 seconds remaining in the buffer). It plays back from the buffer based on a speed controlled entirely by a local clock. This is how digital audio data transfer protocols probably would have been designed in the first place if computers (not CD players that can only read the data at a relatively low speed with a high error rate) had been the most common type of source at the time.
This concept is similar to DAC as clock master architectures. These approaches still have unwanted jitter distortion.
DAC's local clock will have timing errors that displaces samples in time. Such large buffers will add to DAC's complexity and has the potential to make it worse.
(sorry for the delay in replying...I never bothered to follow-up on this analysis because it would soon be irrelevant)Yes, there will always be jitter somewhere deep inside the DAC (hence the opportunity for academics here...a neverending source for analysis!).
But, if the jitter is taking place entirely within the DAC itself, with no external factors influencing it, there is no need for a study of jitter from software, drivers, cables, source components, interfaces, power supplies or quality in equipment other than the DAC, RFI/EMI, etc. In other words...the post is moot if one simply uses a DAC that does not rely on the timing of incoming data (and I don't mean by merely using a buffer to reduce the effect of incoming jitter...I mean dictating the flow of data asynchronously).
By the way, DACs that support asynchronous input are now available (from Ayre, Wavelength, and others in the near future).
Edits: 04/08/09
If your findings are subjective , what is the point of your whole tecnical diatribe....your ACID test might not be mine. Your techical ramblings are no means a support for anything subjective. It's like going into the whole chemical makeup and genetics of a tomato to justify whether you like em or not. applys to you but to no one else.
Rodney Gold
Another rambling attempt to prove his PC transport using a stock soundcard and multiple noisy SMPS units out performs the dCS Scarlatti kit.
Even PC transport using a stock soundcard and multiple noisy SMPS units out performs the dCS Scarlatti kit!
Nonsense
when one has not tried the approach.
Just as it would be nonsense for me to say the cics cMP approach sounds better than the DCS since I have never heard it, are you saying you have?
From previous posts I do not believe you have assembled cics's platform.
I wish I could understand inference when it comes to reading about audio devices; how is this done reliably? An explanation would be very useful.
I remember someone make a comment that 2 identical music files sounds different....... As if that make any sense!
Diversity, not identity is the law of nature. What makes you think that the two files are identical? At the very least, they are stored in different locations. The miracle, and if it occurs it is an engineering miracle , is not that the two files sound different, it is that they sound the same. As with all things, perfection may be sought, but never attained. Computer programmers will not understand what I am saying, but computer engineers will.
Tony Lauck
"Perception, inference and authority are the valid sources of knowledge" - P.R. Sarkar
"Computer programmers will not understand what I am saying, but computer engineers will."
Computer hardware engineers exist merely to provide an as-close-to-perfect-as-possible platform for the software that runs on those computers. Even if they achieve perfection some day, the work done by their perfectly engineered hardware is entirely dependent on the software written by computer software engineers. Most programmers realize early-on that they cannot assume that the device their software is running on is well-engineered, so they must take steps to make their software as "bullet-proof" as possible in order to provide as "perfect" an experience as possible for the users. Therefore, perfection (from the users perspective, which is the only part that matters) from a computer can only be achieved by the people who write the software for it. Hence, the only people involved in the creation of computer-based solutions that can truly understand perfection are the software engineers, not the guys playing around with the circuit boards. 8P
nt
"Clock jitter at the sample clock (LRCK) is most detrimental to DACs (and ADCs)."
I have not found this to be true at all, in fact most D/A converter chip datasheets actually say that the conversion occurs on either the SCLK (bit clock) or the MCLK (master clock), not the word-clock. This is a common misconception.
"Hence noise pollution from data pins and other clock pins will no doubt impact negatively on the sample clock causing jitter."
So-called "noise-pollution" and "RFI" etc. are all words that describe phenomenon that are widely misunderstood. These are usually ground-loops causing "ground-bounce" or they are simply crosstalk or power supply noise.
Reducing jitter in all of the I2S clocks will achieve low jitter in the resultant conversion. I'm not sure I understand what you are saying in your conclusion. There are certainly a lot of sources of jitter in the typical digital streaming logic chain. In your case, you evidently had a mixture of ground-loop noise and jitter, and a miriad of different devices, probably all with non-ideal S/PDIF and clock interfaces. Do you know if the clock cables were impedance matched and properly terminated?
It reads that you are comparing a Transport DAC combination to RME and Juli@t PCI boards, and the RME board was slaved to the external Scarlatti Clock? Is this correct?
Steve N.
I have not found this to be true at all, in fact most D/A converter chip datasheets actually say that the conversion occurs on either the SCLK (bit clock) or the MCLK (master clock), not the word-clock. This is a common misconception.
This may be chip dependent. Point is a clock is marshaling when samples are dispatched be it LRCK, MCLK or other. Whichever one used would trigger the jitter distortion.
Reducing jitter in all of the I2S clocks will achieve low jitter in the resultant conversion. I'm not sure I understand what you are saying in your conclusion. There are certainly a lot of sources of jitter in the typical digital streaming logic chain. In your case, you evidently had a mixture of ground-loop noise and jitter, and a miriad of different devices, probably all with non-ideal S/PDIF and clock interfaces. Do you know if the clock cables were impedance matched and properly terminated?
No myriads of devices in play - just Transport and DAC (and AMPs - no preamp). Component not in use (Scarlatti or AA) is physically disconnected. For soundcard, the one not in use is disabled. Therefore only ONE SPDIF input is connected. No ground loop problems like humm etc..
Clock cables from Crystal as well as dCS stock version.
What I'm saying is: yes a clean clock signal is important and will give sonic benefits as you mention (through reducing jitter). But its not the only factor. My experience suggests care must be taken across all clock inputs as well as data inputs. This is more challenging.
It reads that you are comparing a Transport DAC combination to RME and Juli@t PCI boards, and the RME board was slaved to the external Scarlatti Clock? Is this correct?
Its the total combination (transport, soundcard, DAC) that I'm looking at. Juli@ also performed better when compared to both RME & Scarlatti DAC clock slaved. Currently, RME provides master clock (Juli@ is disconnected - used for recording). For slave configuration, when using AA DAC (which does not allow for clock slaving), only RME can be slaved.
So-called "noise-pollution" and "RFI" etc. are all words that describe phenomenon that are widely misunderstood. These are usually ground-loops causing "ground-bounce" or they are simply crosstalk or power supply noise.
Ever wonder why using a superclock with measured jitter performance below a ps results with DAC jitter thats much higher? This after great care is taken in its implementation (including excellent grounding and power supply). The noise pollution includes EMI (as in induced currents), RF pickup (into GHz), IMD, signal reflections and thermal noise.
Did you try to slave the cMP directly to the Scarlatti DAC since the Scarlatti DAC also has an word clock output?There is a thread on the Slim Devices forum about slaving the Transporter to an external DAC and from the discussion it seems it's better to use the DAC as Master, thus running from its internal clock and send that clock to the slaved source, than to slave both the source and the DAC to an external master clock like the Scarlatti unit.
The starter of the thread has the Scarlatti DAC.
Did you try to slave the cMP directly to the Scarlatti DAC since the Scarlatti DAC also has an word clock output?
There is a thread on the Slim Devices forum about slaving the Transporter to an external DAC and from the discussion it seems it's better to use the DAC as Master, thus running from its internal clock and send that clock to the slaved source, than to slave both the source and the DAC to an external master clock like the Scarlatti unit.
The RME jitter specification is quoted to be <1ns; I can't imagine it providing a better clock and sounding better in master mode than slaved to the Scarlatti DAC. Why not slave it at 44.1k, disable the SRC and let the DAC make any upsampling?Here are a few quotes form the founder of SD from the thread I gave the link in case you didn't had time to read it:
Quote:
Yes it is a manual setting. Please, notice that I use a DAC and en external clock, i.e. two units.?!? Why?
Such a configuration should only be used if you have some requirement to synchronize multiple _source_ components, perhaps for editing purposes.
It is the MCLK (eg 11.2896MHZ) signal that actually drives the internal operation of a modern DAC chip, and the whole point of word clocking (for the purpose of reducing jitter) is to put that clock as close as possible to the DAC chip itself.
A PLL is absolutely _terrible_ at generating a master clock from a word clock, compared to generating it directly with a crystal. But that is not even the only source of jitter - you are also accumulating it in all the connections between this equipment, and in the clock source device itself, as it has to divide a crystal-generated clock internally to produce that low word clock frequency.
I am not aware of any situation where a word clock would be advisable for driving a DAC. You will get jitter much worse than anything you'd get even from traditional s/pdif master-> slave clocking.... i.e. this is not only defeating the jitter eliminating mechanism of the word clock interface, but is actually making the jitter far worse even than plain s/pdif. You are probably running your DAC on a few hundred picoseconds of jitter, as opposed to the 30ps or less that would come from a good quality internal oscillator.
Quote:
2) Even better is to syncronize both the DAC and the Transporter to an external clock - if this clock is of higher precision than the one in the DAC.No, this is where you are very wrong. I have already explained why from a theoretical standpoint, but to put it another way, which do you expect will have more jitter:
- A crystal oscillator running at 12.2880 MH, directly driving the DAC
Or
- A crystal oscillator running at 12.2880 MHz
- driving either a synchronous counter or a series of flip-flops, to divide that signal down to 48 KHz
- then feeding this signal through some transmission circuit to a BNC connector
- coupling that signal into a cable
- feeding it down the cable
- getting it into another connector at the other end of that cable
- driving that signal into a PLL circuit which multiplies the word clock signal back up to 12.2880 Mhz
- feeding the output of that PLL into the DAC chip.
Quote:
Finally, I still can not understand your theory of internal vs external clock (high precision oscillator) for a DAC. Please, notice that both Esoteric and dCS promotes this idea - and for me it works well with the Transporter and 44.1kHz.Which part of it is unclear?
Consider an absolutely perfect clock with zero jitter. No such thing exists, but let's just suppose for the sake of argument that your external clock source is such a device.
Now, divide that clock signal down to word clock speed (/128 or /256), send it through a bunch of cables and connectors, through a PLL to multiply it back up to MCLK speed, and then across another circuit board to the DAC chip. How can that possibly still be a clean clock? How could it possibly be cleaner than if you placed the crystal oscillator right next to the DAC chip? It can not. Not by any stretch of the imagination, and not even if you consider a _perfect_ external clock source compared to the poorest imaginable local crystal clock source. It is not even close. The external clocking scheme is worse by about a factor of ten. In practice you would get about 15-50ps for the internal clock, versus 100-300ps for the external, PLL-recovered clock.
The fundamental principle of word clocking, when used for the purpose of reducing jitter, is that you are eliminating all the crap between the clock source and the DAC. This is where jitter comes from. The quality of the crystal oscillator is actually not even a major factor.
Finally ask yourself, if dCS can produce a better clock signal through such a convoluted means, why would they not then simply build this technology into their $18K(?) DAC? Maybe they just want to sell you yet another overpriced box.
Look, I am not making this up and I have nothing more to sell you. What I am telling you is all solid theory that can easily be tested with suitable equipment. Have a look at this (and also be sure to jump back to part 1 for the introduction):
http://www.tnt-audio.com/clinica/diginterf2_e.html
What you need to do is shown in the "clock backwards" configuration. This is ideal - it puts the oscillator right at the DAC so that the clock signal does not flow through PLLs, dividers, or interconnects.
If anywhere in my reasoning you have found a mistake, please point it out and we can discuss. Otherwise it's pretty silly to just not believe me because my conclusions conflict with what the high priced stereo vendors have told you. There are guys who will sell you lacquered knobs and granite isolation plates too.
Thanks for extracting the relevant bits. I'm familiar with TNT's documentation. A DAC acting as master will still have:
- Loss of galvanic isolation
- Clock circuitry from DAC's XO to deliver signal
- Interface issues (transmission circuit, cable, BNC interface, signal coupling / noise rejection,...)
My learnings suggest that even with an XO placed at the DAC chip and assuming the clock signal going into the DAC chip is clean, contamination occurs. Think about these questions:
- What's inside the DAC chip?
- Why stop just at the chip's clock input?
- What happens with all the other (untreated) signals entering the DAC?
All these additional inputs have an impact on the sample clock. There's an assumption that the sample clock remains pure within the chip. My understanding of chips suggest this assumption is incorrect. Chips internally carry tiny sample buffers, have all kinds of logic circuits to perform filtration, upsampling and so on... This complex circuit is still subject to noise entering it. That pure sample clock does not act in isolation as it is integrated and therefore susceptible to noise.
Anyway, I also plan to measure this scenario (DAC provides master clock to Transport at 88.2k). Yes clock works in multiples of master, ie. 48 will also do 96 and 192 (same applies with 44.1).
RME jitter specs of < 1ns is a guide. Its difficult for manufacturers to provide exact jitter as they have no control over PSU quality and complexity of computer environment. These factors and more destabilize the XO which by itself is actually very good (~20ps).
I cannot figure out what the heck you are talking about here.
D/A converters have four signals typically, called I2S, including:
MCLK
SCLK
SDATA
L/RCLK
Most D/A chips do the conversion on the Bit clock (SCLK) or the Master Clock (MCLK). Depends on the chip which one. The quote from the SD guy says they are all Master Clock, but this is not true. Depends on the chip.
If you lower the jitter on the SCLK, you will have succeeded in lowering the jitter in the analog output for most D/A chips.
If the Master Clock is generated inside the DAC (very rare), and then divided-down to a word-clock which is output to the source device for synchronization, this is the optimum solution. The jitter on the Word-clock to the source device does not matter, as long as its not so bad as to cause errors. This is only necessary to get clean data image into the input FIFO. Once in the FIFO, the output clock is the one with ultra-low jitter. It takes a memory-based system to do this effectively.
The same thing can be done with a memory-based reclocker that sources the master or word clock to the source device, such as the Transporter. The reclocker can then drive all four signals of I2S to an I2S input DAC. This will acheive very low system jitter. Again, the jitter in the clock that is transmitted back to the source (as slave) is a "dont-care". Such reclockers work extremely well, even though they are a "third" box in the chain.
Steve N.
If you lower the jitter on the SCLK, you will have succeeded in lowering the jitter in the analog output for most D/A chips.
I'm not disputing this. You're also correct in that the clock treatment must be on the correct clock input signal (as this varies by manufacturer). Lets call this correct clock signal the master clock.
So, what am I saying then:
- Remaining clock signals entering the chip will carry jitter which is not directly related to the master clock jitter. Of course if these are are grossly jittered other issues arise. My understanding is that for these non critical clocks, level detection is used (as opposed to phase).
- Both the clock and data inputs however carry noise. This noise infiltrates the chip. Noise as mentioned before includes EMI (as in induced currents), RF pickup (into GHz), IMD, signal reflections and thermal noise. Remaining clock signals have jitter which I see as phase noise and this adds to the overall noise contamination.
- If chips are free from such contamination entering it, then yes only the master clock signal needs treatment. This is a large assumption.
Why regard the chip as a 'perfect black box' when in fact its a (very complex) circuit? There's bound to be interference at the master clock signal which entered the chip uncontaminated. This interference manifests as jitter.
"Remaining clock signals entering the chip will carry jitter which is not directly related to the master clock jitter. Of course if these are are grossly jittered other issues arise. My understanding is that for these non critical clocks, level detection is used (as opposed to phase)."
There is only one synchronous clock used on a DAC chip. The others are not effectively clocks. Sometimes the MCLK is used to do digital filtering, but does not affect conversion, which is where the jitter becomes audible.
"Both the clock and data inputs however carry noise. This noise infiltrates the chip. Noise as mentioned before includes EMI (as in induced currents), RF pickup (into GHz), IMD, signal reflections and thermal noise. Remaining clock signals have jitter which I see as phase noise and this adds to the overall noise contamination."
No, only the single clock signal matters. Once the data is clocked into the first flip-flop in the D/A converter, only the clock matters.
"If chips are free from such contamination entering it, then yes only the master clock signal needs treatment. This is a large assumption."
The data can be jittering a lot, but it does not matter. Only the clock matters. This is fundamental synchronous logic. Contamination means nothing. There is no such electrical phenomenon as "contamination", except maybe in water sources or air etc.. It is either timing jitter, ground-bounce or crosstalk.
Steve N.
If there's ripple voltage riding on the data input single (for example), are you saying this will NOT impact jitter? If so, how?
No, only the single clock signal matters. Once the data is clocked into the first flip-flop in the D/A converter, only the clock matters.
Data sent to chip is at bit level where the bit clock matters. How else would the chip determine actual signal amplitudes (16 or 24bit)?
Any time data is moved from one point to another in an audio digital component, that data can modulate the clock because of real impedances in the circuit traces, and in the D/A convertor chip itself. This is especially problematic at very low audio signal levels in a PCM-based system because the two's complement data words go from all zeros to all ones at or near the zero crossing point, and so the music signal, which is repetitive by nature, can easily couple to the clock as data correlated jitter.
As an example, consider a digital filter outputting a 1Khz low level sine wave encoded data signal, along with the bit clock and word clock to the D/A convertor IC. Each of these signals must 'travel' from the digital filter IC to the DAC IC and back. All share the same reference at the DAC IC, but the average level of the data line will alternate between a high and low state, causing the power and the ground to change during the time as well because of the impedance of the power and return paths. This changes the clock threshold level in the DAC IC (as well as modulating the clock amplitude at that same 1KHz rate) resulting in data correlated jitter. Even if the jitter was zero at the output of the digital filter, it is present at the DAC (and easily measurable I might add).
This is the same type of situation you have with asynchronous clocks running a FIFO or any other buffer device. The input clock modulates the time and frequency parameters of the output clock (and vice versa) because they are connected to the same device and hence share the same power and ground system. In addition, the data will modulate the clocks as previously detailed. Every edge transition or level change in the system creates a background of noise on the power and ground lines that will ultimately modulate the clock at the DAC IC. In order to effectively remove the jitter and not reintroduce it requires isolation techniques that are not commonly used and are somewhat expensive to implement.
Very interesting and makes a lot of sense.
With lower levels we get no information in the higher order bits thus alternating signs cause signal changes from largely all 0's to 1's as you mention. This data related noise probably gets worse with increasing frequency as there's more frequent swings between signs (with same amount of unused higher order 0's and 1's).
Many implementations do suffer from ground-bounce and crosstalk, so I agree this can be a problem. I have found that designs in the field of consumer electronics are frought with these problems, even from large multinational companies. Many of the mods that I have done in the past repair these types of problems.
I implement many of the isolation techniques you mention in my own products, so I dont have this problem. My circuits behave closer to the ideal. Separate power feeds, isolated return traces, effective decoupling and termination/impedance matching etc..
This is simply ground-bounce and crosstalk between traces and with power supply. With proper circuit design and board layout, these can effectively be minimized so that they are inaudible.
But I haven't heard your stuff so can't comment on that.
I think we've talked about this before, but separate return paths don't really effectively address the problem since the signals generally all share the same source and return pins. Better to have a close layout with an extremely low impedance return path (typically an uninterrupted ground plane directly above the signal traces) except this isn't always possible if you want the digital filter and all of the other high jitter signals isolated from your clean clock and D/A convertor.
One method that works pretty well for me is generating the clocks in an isolated section (using BB ISO 150 device) along with the D/A convertor and analog stage, and then clocking the data across the barrier. Not perfect, and everybody has their own way, but you have to break the jitter path at some point.
"If there's ripple voltage riding on the data input single (for example), are you saying this will NOT impact jitter? If so, how?"
If the setup and hold times are not violated, then the data will be clocked into the first flip-flop inside the D/A chips without error. If it meets these criteria, then only the clock that clocks the data has any effect on the timing. This is fundamental synchronous logic 101.
"Data sent to chip is at bit level where the bit clock matters. How else would the chip determine actual signal amplitudes (16 or 24bit)?"
Data sent to the chip is either ones or zeroes. It is the output of the D/A where the voltage varies. The contents of each data frame on the input determines the word size. The frequency of the input stream to the D/A chip determines the sample-rate.
There is a lot of misinformation and misunderstanding of these processes. Listen to the engineers that have the education in these areas.
Steve N.
What you explaining is how the chip accurately decodes binary signals, so setup and hold times are important in this regard.
On data input, looking at the AKM DAC example, the following is explained in its operation:
In all modes the serial data is MSB-first, 2's compliment format and is latched on the rising edge of BICK.
It goes on to explain that BICK must present and so on...
What you avoiding is the lack of noise immunity thats riding these signals. A Flip Flop is a switching circuit that still maintains current flow. Noise coupling remains a factor.
cics and all of his groupies should read:
http://boards.psaudio.com/showthread.php?t=3412
http://www.psaudio.com/newsletters/3-08.asp
Bottom line, a Toslink digital output from a stock soundcard isn't going to produce SOA results no matter how much plug and play PC tweaking cics does.
PS- cics have you ever built or modifed/upgraded any DAC?
Noise coupling is not a factor. The data has almost a full half cycle of setup and hold time with respect to the clock rising edge. There are no violations, therefore noise on the data signal is not a factor. Only the noise on the bitclock (SCLK) is a factor.
The kind of noise you are talking about is well below the switching threshold in 99% of designs. If this is not the case, then the design is severely broken and should be redesigned anyway.
Steve N.
"Both the clock and data inputs however carry noise. This noise infiltrates the chip. Noise as mentioned before includes EMI (as in induced currents), RF pickup (into GHz), IMD, signal reflections and thermal noise. Remaining clock signals have jitter which I see as phase noise and this adds to the overall noise contamination."
So isn't this a good reason to not use the clock generated by the soundcard when set to master which will then be sent to the DAC? The clock of the soundcard can't be as good as the one generated by the DAC, not to mention the PC environment isn't exactly helping.
I think this discussion shouldn't be about the shortcomings of different chips. It's all about which component should be the master for the clock generation and I hope you agree with me that the clock provided by the Scarlatti DAC should be much better then the one from the RME card.
For me the ideal setup would be:
An optical connection from the soundcard to DAC for data transmission.
The DAC set as master which will then send its generated clock to the soundcard.
What DAC do you know of that will do this?
Steve N.
Do you mean a DAC with an Optical input and an Word Clock output?
These are a few that came to mind, maybe there are more:
1. Esoteric DACs
2. dCS Scarlatti
3. EMM DACs (only ST glass)
4. Prism Sound DA-2 & Orpheus
5. Digital Audio Denmark AX24 equipped with the stereo AES-SPDIF module.
I shared your same ideal view, ie. optical input and DAC (or external clock) as master. Thats why I bought the Scarlatti Clock.
The clock of the soundcard can't be as good as the one generated by the DAC, not to mention the PC environment isn't exactly helping.
In the paper, following is mentioned:
Computers superiority in jitter performance is not well understood. Consider this: SATA specifications demand strict jitter tolerances for which standards are defined (something like not exceeding 160ps peak). Computer manufacturers utilize jitter testing equipment measuring in femto seconds (a femto is a thousand fold less than a ps)! This is all very necessary to achieve very high bandwidths and extremely low bit error ratios.
Computer manufacturers have substantially more R&D dollars to create faster, cheaper & more efficient products. Because of ever increasing performance demands (faster processors, RAM etc) manufacturers have to reduce jitter to very low levels. This is critical for achieving high bandwidths. Clever noise reduction technologies are being implemented, e.g. DDR2 that has ODT (on die termination) technology that terminates signal reflections within the memory module. Reduction in power consumption demands is also forcing the industry into creating low-power components.
Combining a soundcard (PCI, Firewire or USB based) with a computer allows one to achieve low jitter when correctly optimized. My experience suggests that soundcards have good quality XOs (a must for the recording industry where computer audio is the norm). Yes, computers are complicated animals and offers phenomenal capabilities BUT they come with configurations that suit a general PC user and NOT audio. Such configurations create lots of jitter at the soundcard. The challenge is in reconfiguring it.
Thus, a computer acting as Transport is a perfect platform for low jitter IF configured correctly. Given its processing capabilities it offers another very important benefit: high precision upsampling based on bandlimited interpolation which recreates the analogue waveform. Such reconfiguration of a computer is covered in cMP's documentation (based on Windows XP). Others provide excellent guides for Linux. When fully implemented, the results are very good indeed. So much so that it can act as clock master and question the 'DAC as master' approach! You get all this for $1500. That's how I'm experiencing it and feel compelled to share it.
Sound cards all have very jittery clocks IME. The computer has little or nothing to do with it either. I have evaluated a LOT of different clocks, and found only two that are acceptable to me. One of these is the Superclock4.
The reason that there are superior computer audio solutions to CD players is that the chips available for USB have superior digital PLL's in them. If CD players had minimal buffering and good digital PLL's they would be equally as good.
Wi-Fi has a distinct advantage because the data is networked and packetized. This allows the master clocking to occur at the destination, independent of the source.
If you are looking for really low jitter solutions, spending money on really expensive gear may not get you there. It's making the right choices.
Steve N.
Hi SteveN,
What is the other clock you found acceptable - hope it's lower cost than the Superclock4?
Do you think that 90% of the improvement in putting on a new clock is in the new cleaner/better PS that feeds the clock? If not 90% what figure would you put on it?
The other clock is a trade-secret.
Power subsystem, not just power supply makes a big impact on the superclock and other logic performance. Also the board layout and circuit board layout and design as well as transmission-line terminations and impedance matching also have a big effect. It takes all of this to achieve a really low system jitter.
Steve N.
Trade secret? Why? Is it not commercially available? Is it some new product?
Why not dispense with all this clock business nonesense & go for the ESS Sabre Multi-channel DAC which recovers the clock from the SPDIF apparently without jitter. How its' done is a trade secret but at least it is available!
Apparently? Yeah right, I've heard this before.
Why would I buy another DAC when my own design beats everything I have heard? Only Zanden 5000 comes close...
Did you had the chance to see the Stereophile measurements for the Zanden 5000? There were performed 2 measurement sessions because the manufacturer claimed the first sample was defective. Check the jitter figures on both samples, it really seems like overpriced junk in a shiny box targeted at clueless rich guys...
first sample measurements:
http://stereophile.com/cdplayers/1106zanden/index4.html
second sample measurements:
http://stereophile.com/cdplayers/1106zanden/index8.html
Just because it has high jitter does not mean that it necessarily sounds bad. The jitter spectra could be inaudible to most humans. I have customers with this DAC and they tell me is is very good. Sometimes musicality is more important than detail.
How do we measure musicality?
With our ears, in stereo.
Electronic instrumentation and classical measurement techniques are not able to do it IME. It will take a multi-dimensional measurement to do this I believe, including phase, magnitude and frequency for two channels in a two-dimensional plot. This plot will also need to be swept over gain settings so that compression due to absolute level can be observed. Nothing like this has ever been done to my knowledge.
Steve N.
Have a look over at DIYA - design engineer has been posting & sending out sample boards - so it's not marketing hype as before - it is standing up to the claims made of it!
Why the trade secret clock - you didn't answer this?
Of course I didnt answer. It's a trade secret. We manufacturers have to have some of these otherwise our competitors just steal everything and put us out of business. Patents I have lots of. They are worthless unless you are willing to spend $100K in court.
I guessed as much about your post - all smoke & mirrors ("trade secret") - just a lot of bullshit being passed off as mystique - unfortunately, a common problem in this area called HIFi!
Good to see Stereophile expose some of the pretenders, whoever they might be!
My products speak for themselves. It's all about the engineering. I'm an engineer with 30 years design experience. I dont ever lose in shootouts.
OK, I didn't realise you were a manufacturer - then it's understandable that you protect your IP, I agree.
It also explains your reaction to the ESS Sabre DAC I mentioned!
They dont allow me to identify myself on this forum. Against the rules.
If you use Superclock4 as a reference, then soundcard XOs would be poor.
Dunn suggests jitter below 20ps is inaudible. I'm using this as a reference for which professional soundcards can be compared to.
I dont give a hoot what someone suggests. In a highly-resolving, low-noise system you can easily hear the difference between the Superclock4 and a Superclock3 for instance, and they are both probably sub-100psec in jitter.
Steve N.
"I hope you agree with me that the clock provided by the Scarlatti DAC should be much better then the one from the RME card."
cics doesn't agree with this. He thinks his cMP (RME set as Master)sounds best.
I agree the clock in the Scarlatti DAC/Clock should be much better then the one from the RME card, but once you connect them to the RME card they're exposed to the noise contamination from his cMP.
| FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
||||||||||||||
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2024, Audio Asylum, all rights reserved ]
