The battle of the DACs, comparison of sound quality between some DACs

Status
Not open for further replies.
No, I really think it is reasonable conclusion. If a poor oscillator is only very slightly inferior to Andrea's clocks then it is a totally reasonable conclusion that low close-in phase noise is not that important.

For every single type of dac architecture?

How do you personally define a 'poor' oscillator as verses a 'good' one, in terms of close-in phase noise measurements?

Is your 'conclusion' merely an opinion stated as if it were fact?

Please sir, live up to your own standards as you would like to see other people do.
 
  • Like
Reactions: 1 user
One aside, if I may: For all the many people who have compared listening to Crystek, Accusilicon, and or NDK SDA clocks in some board that allows it, such as FIFO_Pi, they all sound pretty awful, with Accusilicon usually coming out as preferred. Those same people may find plugging in one of Andrea's clocks provides a dramatic improvement is SQ.

I have put off probably for too long talking about my findings and thoughts on that. The biggest problem is almost certainly with Ian's clocking implementation. Is how the clocks are powered, bypassed, buffered, etc. Andrea's clocks are separately powered, well implemented, and well buffered before going into FIFO_Pi.

Ian measures jitter with a scope jitter measurement package, not a time pod or similar instrumentation that is specifically for close-in phase noise.

Anyone's guess if any of the other measurement-oriented guys are doing better or worse relative to Ian.

The above thoughts are all I am going to share on the subject for now.
 
Last edited:
  • Like
Reactions: 1 user
Regarding ENOB: from an error budgetting point of view, you normally like the analogue noise to limit the signal to noise ratio of a sigma-delta DAC, because reducing the digital noise by adding an extra bit is much cheaper than reducing the analogue noise by 6 dB (for a given architecture, that typically means quadrupling the analogue area and current). Hence, you get an input word length well above the ENOB.
Thanks, for that clarification, Marcel. Many years ago, one of the projects I was involved with was the development of a digital cordless telephone chipset. The part of the team working on the frequency-hopping radio would always talk in terms of link ENOB for, as you indicate, link error budgeting. I didn’t know too much about digital radio links, so it was then that I started the habit of sometimes improperly referring to signal domain conversion SINAD losses generally, in terms of ENOB.
 
Last edited:
One aside, if I may: For all the many people who have compared listening to Crystek, Accusilicon, and or NDK SDA clocks in some board that allows it, such as FIFO_Pi, they all sound pretty awful, with Accusilicon usually coming out as preferred. Those same people may find plugging in one of Andrea's clocks provides a dramatic improvement is SQ.

I have put off probably for too long talking about my findings and thoughts on that. The biggest problem is almost certainly with Ian's clocking implementation. Is how the clocks are powered, bypassed, buffered, etc. Andrea's clocks are separately powered, well implemented, and well buffered before going into FIFO_Pi.
I implemented NDK SDA with its own power supply separate from Ian's FIFOPi and changed out his ceramic caps, added a supercap and a BG HiQ and sound was substantially better than NDK simply plugged into Ian's PCB. Then replaced NDK first with Andrea's gen1 drisco and it was clearly better than my NDK efforts. Upgrading to his 5MHz current Drisco brought a small but worthwhile improvement particularly with ReclockPi & SinePi.
 
D

Deleted member 537459

[/QUOTE]
One aside, if I may: For all the many people who have compared listening to Crystek, Accusilicon, and or NDK SDA clocks in some board that allows it, such as FIFO_Pi, they all sound pretty awful, with Accusilicon usually coming out as preferred. Those same people may find plugging in one of Andrea's clocks provides a dramatic improvement is SQ.

I have put off probably for too long talking about my findings and thoughts on that. The biggest problem is almost certainly with Ian's clocking implementation. Is how the clocks are powered, bypassed, buffered, etc. Andrea's clocks are separately powered, well implemented, and well buffered before going into FIFO_Pi.

Ian measures jitter with a scope jitter measurement package, not a time pod or similar instrumentation that is specifically for close-in phase noise.

Anyone's guess if any of the other measurement-oriented guys are doing better or worse relative to Ian.

The above thoughts are all I am going to share on the subject for now.
thanks @Markw4 for your sharing. I have done about the same tests, I add that I have also tried new class d neutrino and ns2. I have always preferred accusilicon until I mounted andrea's clocks. I believe that real audio is studying, rehearsing, listening and discussing. no studying and giving judgments without having tried or heard.
 
  • Like
Reactions: 1 users
For every single type of dac architecture?
Those who claim that low close-in phase noise is of utmost importance have not made any exceptions between DAC architectures so why should it be different if an opposite claim is made? According to your listening tests close-in phase noise is not that important for DACs used in your tests (DS & R2R).
How do you personally define a 'poor' oscillator as verses a 'good' one, in terms of close-in phase noise measurements?
Ask Andrea who claimed that Crystek 957 is a poor oscillator.
Is your 'conclusion' merely an opinion stated as if it were fact?
My conclusion was based on evidence provided by you and Andrea. Maybe you can provide an alternative conclusion based on the same evidence.
 
  • Like
Reactions: 1 user
The biggest problem is almost certainly with Ian's clocking implementation. Is how the clocks are powered, bypassed, buffered, etc. Andrea's clocks are separately powered, well implemented, and well buffered before going into FIFO_Pi.
Close-in phase noise is a property of the crystal. Ancillary circuitry mainly impacts far out noise floor. So if proper clocking implementation mitigates the issues of higher close-in phase noise then it just confirms that low close-in phase noise is not that important.
 
Status
Not open for further replies.