When a noise peak becomes larger than Fo itself, its time to rebadge the oscillator with a new frequency 😉
//
//
Just the picture about the given wave file:
- the contribution of the ADC (RTX) is unknown, this means a part of the measurement/wave file.
- but shows the final analog behavior, so timepad measurements comes first a the clock and final the overall jitter/noise contribution last
to understand about, look here other measurements given at Article: Understanding Digital Audio Measurements | Page 5 | Audio Science Review (ASR) Forum
- the contribution of the ADC (RTX) is unknown, this means a part of the measurement/wave file.
- but shows the final analog behavior, so timepad measurements comes first a the clock and final the overall jitter/noise contribution last
to understand about, look here other measurements given at Article: Understanding Digital Audio Measurements | Page 5 | Audio Science Review (ASR) Forum
Attachments
Somehow maybe the RTX is in need to be compared to this so we can understand its stability:
zfe measurement
But the RTX contains a NDK so maybe that trace actually come from RTX - zfe?
If thats the case, would it be fair to say that half of the anomalies stem from the DAM and the other from the RTX? The clocks frequency stability seem to be in the same ballpark.
//
zfe measurement
But the RTX contains a NDK so maybe that trace actually come from RTX - zfe?
If thats the case, would it be fair to say that half of the anomalies stem from the DAM and the other from the RTX? The clocks frequency stability seem to be in the same ballpark.
//
I already asked how the Godfather AP555B performs in this regard,
this means ONE HW GEAR as a DAC and ONE Different as the ADC...
So one has two of them on bench to measure (non coherent measurements)... while it is a hen and rooster question, so be prepared for outcomes 😀
Currently I am still on the root of an ultraissmo low phase oscillator 😀
Accusing me for that :-D
The latest zfe showing level differences over time is surely frequency walk (aka: wonder) and not jitter (my jitter definition above!!)
//
The latest zfe showing level differences over time is surely frequency walk (aka: wonder) and not jitter (my jitter definition above!!)
//
But with a fanatic starter instead 😉
Yes, I might be a little fanatic about the possible missed out sound quality - guilty as charged. But not about PN.
//
Yes, I might be a little fanatic about the possible missed out sound quality - guilty as charged. But not about PN.
//
Here's 75 minutes of the 11025 Hz tone with the sound card (RME hdspe AES) syncronized via AES/EBU. Interestingly enough, there is no settling phase, maybe because the frequency actually stayed the same (just switching from WC to AES) and the DAM1021 didn't actually initialize again. There are no "islands of stability" but the overall quality is very much comparable to the version clocked via WC.
I am certain it is not an artifact of the AD converter I recorded it with, because a different DAC with advanced re-clocking features (Lynx Aurora16) didn't show any deviation from correct performance. It does not sound nearly as good as the DAM1021 though. ;-)
I also tried the DAM1021 with a different AD converter (Prism AD-2), same thing.
I am certain it is not an artifact of the AD converter I recorded it with, because a different DAC with advanced re-clocking features (Lynx Aurora16) didn't show any deviation from correct performance. It does not sound nearly as good as the DAM1021 though. ;-)
I also tried the DAM1021 with a different AD converter (Prism AD-2), same thing.
Attachments
Last edited:
No kind of fanatic there, the measurements talk themselves.
The measurements demonstrate that the devices of that thread are in the region of the Oscilloquartz BVA and the Wenzel BT ULN (maybe better).
No claim without proof there.
I forgot, the 22.5792 MHz oscillator (5.6448 MHz plus a pair of frequency doublers) is 3 dB better than the MSB Tech Galaxy Femto clock.
Claim with proof there.
Last edited:
I think the question isn't about the quality of your clock, but if this level of quality is actually necessary. The debate is still open regarding the continuum from "clearly audible improvement" over "a matter of diminishing returns" to "crossed into barking up the wrong tree territory because the rest of the converter isn't capable enough or the human ear doesn't care".
Currently it seem very much like the DAM1021 isn't working as well as it can not because of intrinsic clock jitter, but because of the re-clocking implementation - hopefully mostly software and pray that the day Soeren adresses it will come soon. Then, and only then is there any point in comparing the DAM1021 as it is vs. with a different on-board clock. A comparison that would be without the filters, of course, which I have come to understand are absolutely essential for adequate reproduction of audio material.
Yeah Yeah, and the RTX clock by supernatural means follows the pattern of frequency changes of the DAM Clock measured by an frequency counter 😉
The unregulated DAM clock (as well as the NDK) is much more stable (see my earlier measurements). So the oscillations we see at the DAM clock plot are due to the regulations of the FIFO. The pattern has thus nothing to do with the clock performance.
I know this, my joking answer was for TNT who continues to make fun of the phase noise performance of the clock.
I got to beat him at his own game.
Joking aside, IMHO the problem is just the PLL.
On the other side with such small FIFO the PLL is the only way to track the input avoiding the FIFO to get full or empty.
But unfortunately the results is a source dependent DAC as reported from many members (just to clarify that were not my claims).
A larger FIFO is mandatory to get a true isolation between the source and the DAC. And solely a larger FIFO is not enough to get a proper isolation.
To achieve the best isolation the master clock should be placed at DAC side, with the FIFO slaved to it.
So I believe that in application where a large FIFO latency is not tolerable the FIFO itself should be avoided and the source should be slaved to the DAC master clock (like in some USB to I2S converters).
Distorted sound
I have the first version of R2R DAC 1021. Occasionally there is very distorted (like clipped) sound from both channels - haven't checked it on the scope yet. The solution is to restart the DAC, once or two. Does anyone have the same problem and know how to fix it?
I have the first version of R2R DAC 1021. Occasionally there is very distorted (like clipped) sound from both channels - haven't checked it on the scope yet. The solution is to restart the DAC, once or two. Does anyone have the same problem and know how to fix it?
Fixing what has been discussed via a software change seems very unlikely. Wishful thinking, more likely.
Maybe the question should really be, "How much more would you be willing to pay for the dac if it had an improved clocking and synchronization system, say, of a particular performance level?"
Maybe the question should really be, "How much more would you be willing to pay for the dac if it had an improved clocking and synchronization system, say, of a particular performance level?"
Last edited:
Well, Soeren did promise (for quite some time now) to change the way the DACs adjust the re-clocking frequency. This is what a lot of us here are waiting for.
The world 2.0 where everyone solve any problem with the software (I have been working as an IT consultant for 35 years now).
But it looks like they forget the software runs on the hardware.
Because understanding and working on the hardware is much more difficult (RF is an ugly beast).
May first to pin to the trough how
. Analog PLL works, fine phase locking for the 0.xxx ppm freq. diff as seen in all SPDIF receiver chips
. Digital PLL works, freq. stepped based tracking and regulation ONLY 😱 ...??
So
to clear up the facts 
aboutOr simple within 2 years warranty to send it back for repair & fix