DDDAC 1543 DAC Mk2

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Doede,
I looked at your latest work, the DDDAC 1543 DAC Mk2. It looks like you invested a lot of time in it. While it looks impressive there are several things that could have been done better and I think you and others can learn from this critique.

It is established practice in digital design that whenever a signal enters a board it enters through a receiver. That is important in maintaining signal integrity. Similarly, whenever a signal leaves a board it leaves through a driver. Daisy-chaining a signal from board to board is very bad practice.

In your DAC, the two of the three I2S signals, FS and DATA, originate from ordinary CMOS outputs, not drivers, and have to propagate from the receiver board to the master DAC board and then to additional slave DAC boards. When originating from the USB receiver, those signals have to make an additional hop. Although each DAC board presents a single CMOS load, you have to consider the load and propagation delay created by the additional traces and wiring. I doubt the signal that leaves receiver board (unloaded) looks anything like the signal at the end of the line of a full, five-tower setup.

The situation with BCK is very much worse. Didn’t you read the specs for the TentLabs XO? Like most XOs, its output drive is specified as three HCmos gates. In its minimum configuration, you are asking BCK to drive three gates and a whole lot of additional traces and wire. It would have been preferable to have the three I2S signals fanout from the receiver board through three clock drivers. Clock drivers have one input and 4-10 outputs that have minimal jitter and skew.

I’ve been examining the DAC-AH, which is very similar to your design, and I’ve noticed horrendous crosstalk. I suspect your design, with its stacked DAC chips, is probably a litter worse. The problem is that when one channel’s output is switching to a higher output current, it puts a heavy dynamic load on Vref and that starves the other channel. I believe the dynamic loading and slow Vref recovery causes of the very long and bouncy settling times I see in the DAC-AH. At the very least, each DAC chip should have its own Vref power supply nearby.
 
I never turn to personal attacks. It's dishonest and only makes you look foolish. Ulas, I make an exception just for you.

I have no other option but to conclude that you are a fraud. I do not believe for a second you work with the things you say. Nobody on the planet would hire somebody with absolutely no social competence. 10 to 1 you still live with your mom, the only person that possibly could stand somebody like you. You are pathetic.

Look up APD. Then seek help.
 
Having spent the better part of 3 decades in the technical arena, I have to tell you, phn, a tendancy to bluntness verging on rudeness and less than desirable people skills are all too common in this arena. Frankly, the latest missive from Ulas seems rather innocuous.
 
Maybe so.

Unlike some other people I was very forgiving about his "DAC Settling Time" post. Let's face it, most of us have written a sentence we immediately have regretted. So I'm not going to judge anyone on that.

I have nothing against bluntness. If anything, I welcome it. You should always say what you mean.

Anyway, I expected to be sent to the sin bin. Would have been my first time.

Forgot. As for the Antisocial Personality Disorder, I wasn't kidding. I did a piece on that in HS, as part of (equal to) Swedish Lit. If I remember, 1/10 of the population suffer from APD to some degree or other.
 
Having spent the better part of 3 decades in the technical arena, I have to tell ... a tendancy to bluntness verging on rudeness and less than desirable people skills are all too common in this arena.

Ever sit thru a design review meeting? The above critique is a tea party to some I've seen. Basically the only real issue raised was the need for better buffering and fanout management. Something that frequently gets overlooked in a lot of work that I've seen and I have missed it too at times. But it's like getting a B when you were hoping to get an A. I don't think I've ever been to a design review of other's work (or mine!) that didn't yield at least one action item to correct something. Anyway, I almost perfer bluntness to sugarcoated criticism anyway..:rolleyes:
 
Whatever the shortcomings of the DDDAC, if any, I don't care. I have one connected to my system and it is by far the best source I have ever heard in my system. In this regard I am grateful that there are people like doede that takes the time to make DIY available to the masses.
 
Well I don´t understand all this emotional rallying around the dddac as if it is somebodys favourite football team that was being trashed.
I have one and it is very good and I ilke listening to it.I have congratulated Doede of course.
However if there are some valid technical issues to be raised , even if in an unsolicited manner, I would be interested to hear about them and possible improvements to this excellent design.
There is always room for improvement in every design.
Of course it would have been much more interesting if the thread starter had actually tested one of the dddac´s and applied perhaps his proposed remedies.Anyway it is a good basis for discussion.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.