SB3 vs Duet output noise

[Themis]

Alright, I think I get the idea. Never mind about the graphs, your textual explanations helped a lot. Thanks once more !

[Pete Fowler]

But the real problem is that the clock and SPDIF functions share the same chip. You can see modulation on the Vcc pin, in sync with the source material. Again, you have to look for it, and it takes some equipment that the average guy does not have available. The noise on that pin helps to obscure it. That is common to both devices. That is probably the one thing that I would change if I were the designer of this product.

Pat

Hi Pat,

Thanks for posting your graphs - based on your results I built a linear supply for my Duet receiver this weekend and it improved the sound significantly. Your comment above makes me curious about other ways to improve the quality of Duet using the onboard DAC.

I'm guessing here, but would a clean 3.3V supply to the rcvr chip, DAC and master clock chip improve the analog out significantly? Or minimally to the clock and digital side of the DAC chip? There is a bit of room in the Duet case so I think a separate linear 3.3V supply might be do-able by tapping off the linear 9V supply as it enters the case.

I'd prefer to optimize the existing circuit rather than add an external clock, etc. Or am I fooling myself?

Many thanks,

Pete

P.S. Where in TX are you? I live in Austin.

[ar-t]

There is a thread over at AC, where I start to roll out our "not-so-secret" product. I have done some of that. I have no idea how it sounds because...............none of us here have any MP3s or ripped CDs. (Old guy syndrome.)

I concentrated just on fixing the SPDIF output. We plan to introduce some products that could benefit from a good PC-based source. I did futz around some with the clock to the DAC chip itself. It comes out of a FPGA, and that is never good for jitter. However, it would take more than just cleaning up the master clock. You would have to reclock all of the signals coming out of the FPGA in order for it to work.

I may consider making a special version for those who use the analogue outputs. As I said, this only concentrates on the digital output.

We are north of Dallas.

Pat

[Pete Fowler]

However, it would take more than just cleaning up the master clock. You would have to reclock all of the signals coming out of the FPGA in order for it to work.

Pat

Ouch! I don't think I'll go there - too many ways to make things worse. I appreciate your advice.

Pete

[seanadams]

I did futz around some with the clock to the DAC chip itself. It comes out of a FPGA, and that is never good for jitter. However, it would take more than just cleaning up the master clock.

I'm not sure if I follow you, but I know for sure in AKM's DACs, and I would suspect in any modern DAC, that it is clocked only by MCLK. In other words, jitter on the bit clock, l/r clock, and serial data line do not affect the conversion timing.

So, if you suspect the CPLD is a major source of jitter then all you have to do is re-clock the MCLK (or the s/pdif output). However, one challenge with bolting on a reclocker is that unless you choose to support only one sample rate, you still need logic to select the clock source. And then you end up more or less back where you started in terms of clock path complexity. I suppose you could improve either the dac or the s/pdif by optimizing the layout for one or the other...

[ar-t]

Yes, if you stick in a reclocker, you are locked into one sampling rate.

I have run into problems in the past where sticking in a clean clock doesn't work the way that one expects it to. Everything looked good on the 'scope, but it didn't work properly.

Some DACS work best if you run a "stopped clock". This is where the clock is stopped x cycles after the conversion. Some of the BB DACs are like this. So, you either have to run the clock continuously, and the noise level goes up. Or, it doesn't work if you stop it at the L/R conversion point.

So, if you have the space, and can deal with all of the other issues reclocking brings to the table, it has a way of solving those issues.

What this all gets back to is noise on the Vcc and ground pins. The power supply rejection ratio is only 6 dB at the midpoint of the waveform. Chips with a lot of stuff going on pass all of this noise on, attenuated by only half of its value. Remember, the midpoint is where the decision point usually is. Not a good time to let noise find its way into the data.

Pat

[ar-t]

We tried sticking a clean clock into the DAC on a Duet some months ago. It didn't work, and I am just as puzzled now as I was then.

Even more puzzled. I still can not think of a reason why it would not work. There did not seem to be a timing issue.

But timing issues are something us analogue types don't get, which is why we are analogue types, and not digital types. (Most "digital" is analogue to us, up until you get into the "when" department. All the rest: supplies, ground bounce, bypassing, reflections.....all stuff we get.)

Anyway.......even though I had more important tasks last night, I operated on a guinea pig Duet, to get a clean clock into it. The clock out of the big logic chip runs continuously, so no problem (in theory) to just shove one into it.

Took a few tries to get it working. I suspect it is an issue of how fast the clocks come up to operating level. (Ours takes a while.)

Previous attempts only yielded a distorted tone, using test tones stored on the HD (supplied by someone else, who claims they are fine.) Eventually, once all the clocks operated at the same time, it worked.

We has suspected something like that the previous time, but were unable to cure it. Likewise, we have run into this problem more than once in the past. Since all we do is 44.1 kHz work, locking onto one frequency has not been an issues. (You may not be aware that we used to manufacture CD players and DAC boxes in the past. The latter full of PLLs and reclockers.)

So, based solely on previous bad experiences, we have adopted a "reclock it all" attitude. Even when the all you need to do is get a clean 256 Fs clock into the DAC.

Speaking of which..........

The DAC chip is the most important chip to get a clean clock into. You need to think your clock distribution scheme around the DAC. Everything else is secondary. Easy to do in single frequency units. Multiple sampling rates make things much harder. I have helped out buddies who had to build 44 and 48 kHz DACs. They soon found out why we ditched that approach, and made our DACs audio only. (One friend in particular built a DVD player that not only had to do 48 kHz audio, but also the video. I think he went bald in the process!)


Anyway....the point to all of this is twofold:

The clock to the DAC must come straight from the clock itself, and not through chips doing another function. OK, multiple clock rates mean some sort of multiplexing. The clock must then go through the simplest chip scheme possible.

You also have to take into account how many other places the clock must go. What happens when you have to send the clock to more than one place has its own set of pitfalls. Since the distance the clock must travel will be different to each location, that means that any reflections will arrive back at the clock at different times. And that leads to aberrations on the waveform.

It is these subtle little things that differentiate good performance from great performance.

Anyone who does any sort of design work in this area should read both of Howard Johnson's books on high-speed design. Even analogue types like me have (or at least should have) read both of them. Highly recommended to any serious designer.

OK, enough o/t ramblings. Just found out the power transformer that I designed in last week is now special order this week. Back to the drawing board(?).


There are days that I really hate this business.........

Pat

[nossaile]

- based on your results I built a linear supply for my Duet receiver this weekend and it improved the sound significantly.

Pete: It would be interesting to hear about your tweaks and if you want more ideas feel free to try mine, see http://forums.slimdevices.com/showthread.php?t=51462

[nossaile]

OK, here are the plots that I promised.

Pat: What loads did you use during your noise measurements? Same on both channels (both the one you tested and the "resting" one)? As you may know depending on what causes the noise the result can be highly dependent on size and characteristics of the load.

[ar-t]

The test equipment is the load.

Someone asked me a question, and I can not find where, but hopefully they will find this answer.

I was asked about HF noise out of the Duet, wrt the ferrites in the analogue output.

I measured the noise on our "audio" spectrum analyser.

(OK, 40 MHz isn't really audio, but we used to joke that anything below 70 MHz was "audio". This mainly referred to the baseband signal that modulated the gear I worked on. The gear had a 70 MHz IF section, and the baseband ran from 308 kHz to 8.5 MHz. So, to those of us who designed the IF chain, anything below IF was "audio".)

OK, back to the measurements...........

I saw nothing over that frequency range that changed with the removal of the ferrite bead.

So, for those of you who are not making these things by the millions, I think it is safe to remove the bead.

I do use a lot of ferrite devices, but they must be used judiciously. They always screw up the sound in some manner. In some places, it is not always practical to get rid of them.

I would go out of my way to not have any in the audio chain. However, we do not make stuff by the millions, or even the hundreds. There are EM compliance issues that you must deal with when you make that many. You have to protect against not only egress, but also ingress. Sometimes you have to do what it takes to get that fancy sticker on your equipment.

I do not envy anyone who has to deal with such issues. Being the smallest fish in the pond allows us to escape such scrutiny. That is the one area that niche manufacturers have an advantage over the larger competitors. We can do stuff that works best for sonics, but would not fly in the realm of commercial regulations.

Pat