DAC64 & Torodial power supply

the clock upgrade will probably still improve things as the interconnect isn't the only thing that can introduce jitter. also it's probably worthwhile getting the power supplies inside the transport looked into.
another thing to do that would be dirt cheap is look at dampening the transport's casing and mechanism there should be some faq's about this in the diy section somewhere but the general idea is to deaden the case with car sound damping stuff 'brown bread' i think it';s called. also judicious aplication to the actual transport mechanism and certain components such as the existing clock and various capacitors can reap benefits too. also if you want to take this further you could use silver foil to shield certain internal wires and if there is a captive power lead, replace it with an iec plug or jsut snip all but the last bit of it off and attatch a new iec adaptor.
zanash is the one to talk to about this as he took a heavily modded 25 quid denon to a bakeoff and it held it's head high against a chord, CAL tube dac and a mitchel gyrodeck.
cheers

julian

 

Steve, if you can it would be worth seeing if you could borrow a really good transport for a day or two just to see if it makes a worthwhile difference.

It's my belief that when using the optical link the DAC64 is largely transport independent.

Michael.

 

Julian you are under the impression that transports make any difference at all, shame on you on, and not even a sniff of a DBT.
Manufacturers are just plain greedy knowing full well that they can charge 'x' £££ more for basically and empty cdp case with no dac section in it how dare you!!!!!
I mean the chord dac 64 is the most shinning example of them all 'Transport in sensitive' how could you even comtemplate such a thing Chords super dooper beatsie can tolerate a tosch 220 & and DCS verdi and still sound the same, and as if to re affirm this the 'Blu transport' is released for a mere £4200 to cement this union.
Me I'm off to by a TT

 

sorry tone i'll get me coat....
cheers


julian

 

Tone - a touch of sarcasm perhaps? I think we need to put it to the blind test DAC64 with a handful of transports with optical out.

As for Chord's "Blu" transport our local Portuguese hifi scribe has been testing it with his DAC64 with all the dual BNC 192kHz links etc and he prefers his existing transport (an SACD player I think, can't remember which) with the optical link

Unfortunately, I recently sold the only other "transport" I had which had optical out, a Sony Discman so I can't do any tests at home.

Michael.

 

Excellent Idea Mike I've never did the toslink test when we upgraded the last 64, although we did try 6 different transports, all using same cables (mains,digital) low end Marantz, DV27,Wadia 8, pioneer 565 (tweeked), Teac T1 (tweeked) and a Classe' cd3 and they all sounded exactly the same, even though the scope patterns (output digi signals) were all different ,they sound was the same, without question a DBT could not have yeilded a thing
Yes conclusive proof that transports make no difference at all (AES/EBU & SPDIF) spdif was used all on of the tests, and seperately on the classe & wadia.
Yeah right
But then It's all bollox any way, and our imagingation takes away with the fairies to a land long ago were wheels were square and made of stone.

 

Given the limitations of TOSLink, then they might indeed all sound the same. Would that prove that it was transport insensitive, or that running any transport through a TOSLink connection makes them sound all the same?

Of course, it's quite likely, as I think WM has already stated elsewhere, that the TOSlink connection won't allow any eletrical interfernce potentially generated by the DAC64's SMPS to end up in the transport, which itself, if this occurs, could be the overriding factor why TOSLink (itself inherently flawed to my mind) would sound better.

Then if the DAC64's performance potential is indirectly related to the to the susceptability of the transport in uses's susceptability to conducted RF through the SPDIF output, then it's going to be far from transport insensitive for electrical connections. Is this why the optcal connection is better, I wonder?

I'm only hypothesising though.

I think, IIRC at julians, the DAC 64 wasn't cable or transport insensitive via SPDIF, can anyone else recall this was the case.

Cheers

 

Here's the thing:

1) DAC64 is totally immune to jitter. Totally.
2) With non-optical cables differences in cables and/or transports are due to differences in noise and electrical interference coming down the cable which introduce noise into the DAC64s circuitry.
3) If an optical cable is used, there's no electrical connection so no noise introduced via the digital link.

However, it's still concievable that noise generated by the transport could enter the DAC64 via the mains, which, when using an optical cable, is the only electrical "connection" between transport and DAC. In that sense a less noisy transport could sound better, even if an optical cable was used, so you're better off sorting out a transport from the mains and PSU perspective perhaps than clock upgrades or fancy (and expensive) digital cables

Here's an experiment (if it's possible):
Get a DAC64 setup and then have 2 or 3 different transport with optical outputs to test. However, (here's the tricky bit) get the transport to run off a battery or some other power source that's totally independent from the mains that the DAC64 is running on.
If you can then hear differences between the transports there's a Nobel prize in there for someone because something beyond the laws of physics would be happening.

Michael.

PS: on the clock mod front, it's still worth it, depending on how bad the clock in your transport is. The DAC64 has it's own clock which reads from the buffer that's totally independent and not linked in any way to the transport clock (ie the clock signal incorporated into the SPDIF signal). With a 4 second buffer the two clocks would have to drift apart by more than 4 seconds before the DAC64 went into failsafe mode and linked directly to the input clock (cancelling the use of the buffer). If you leave your transport and DAC64 on all the time and you find from time to time that the DAC has gone into "no buffer" mode (it has happened to me before) requiring a switch off and on then a better clock would solve that problem.

 

That's exactly it and precisely why Rob Watts recommends the use of optical connections. However, it's not the DAC64 sending noise to the transport, it's the other way around. The variance is the noisiness of the transport affecting the DAC.

Provided you can totally eliminate jitter (which the DAC64 can) why is TOSLink "inherently flawed" ? All the issues are to do with conversion to electrical, crap TOSLink receivers/senders etc but those are all jitter inducing problems which aren't a problem with the DAC64.

Michael.

 

A mate of mine might be bringing over an Arcam CD82 on Sat so if he does we'll sit down & have a bit of a comparison session through the toslink connection.

Michael, apart from the music starting as soon as you hit play is there a visual indication on the DAC that its entered failsafe mode. i.e. do the yellowy green LED's switch off ?

 

TBH I didn't check whether the buffer light (yellow/green leds) went off but it's immediately apparent that the music starts straight away with no delay and there's also a very noticeable degradation in sound quality.

Michael.

 

This is a corker mike, please go into further detail, greatly please, as jitter is measureable artifact prehaps dean could bring his along and we'll do some 'Myth bustings scans on it'
So if we have a 'noise quite transport', with an electrical conection, with your thereoy should be as good then
If it's that jitter free why need to have a better transport, by rights it should process the signal and remove ther digital artifacts within it's fifo buffer and internal PLL
Prehaps a better way to up the transport would be to have seperate power suppiles to the toslink sections and isolate them and up the transceiver arrays, (it works for the AT&T on the Glass optics) but still I prefer AES, maybe we all have much quiter noise in our systems then

 

I dont buy that...

 

Hmm... we've had this discussion a couple of times now, and it seems to my little brain that it boils down to this:

IF the DAC64 is jitter independent then Michael's argument has to be right.

If on the other hand it isn't jitter independent then the whole different connections and transports debate is opened up.

Surely the first question should be is it jitter independent or not?

 

I don't buy that either.......

Let's say for the sake of argument, that Mike's right.

Jitter can only be eliminated by a PLL (Phase Locked Loop), and this will be clock controlled and will empoly a re-sampler to give a signal that is theoretically jitter free to present to it's own DAC.

But surely somewhere in that process, there is a sample and hold filter so that it can fill up it's 4 second buffer or whatever it's got. That sample and hold filter will have to use one of the clocks as it's trigger, but it will surely only see whats at the sample and hold stage at that time. If there is significant jitter on the incoming signal, then it may not be at the right value when it's sampled. Therefore jitter free or not, it is a corrupted signal at that point if it's using the DAC 64's clock for the job.

It can only work if the DAC 64 recovers the the clock signal from the transport to run the sample and hold buffer. This would mean that, for as good as the transport is, it will at least be using the right timestamp to fill the sample and buffer, and will see the transports idea of what the signal should be and correctly store it in the 4 sec buffer. This means however that it can not be transport independant, whatever it's doing with any jitter!! It still uses the transports idea of where the 1's and 0's are, and some are better at error correction than others, and as they all read in real time and fill in the gaps, no matter how thoroughly the DAC 64 deals with what it has to assume is the correct reading of the disc at the input.

Still, I'm no convinced it's jitter free anyway, no clock has no jitter, even the ones that cost 3 figure sums to buy.

Cheers

 

OK - first let me make one clarification: by "totally immune to jitter" I mean "totally immune to jitter in the incoming digital signal". Clearly the DAC64's internal clock and buffer reading circuitry may well be subject to jitter but that would be the same regardless of the transport used.

Whether the DAC is immune to jitter on the incoming SPDIF signal is pretty hard to measure. You'd have to scope the incoming signal and then stick a scope somwhere in the internal circuitry and compare but that wouldn't really tell you anything.

Wrong. That is the way that nearly all DACs do it and it can be very effective but it does require that the clock of the DAC is at some level linked to the incoming clock signal. In the DAC64 this is not the case, it's the fundamental difference of the DAC64 to all other DACs I know of.

In the DAC64, the digital receiver puts the 1s and 0s into a buffer. When there's roughly 4s worth of data in the buffer the DACs own internal clock which is in no way connected to the incoming clock signal starts reading that buffer and making music out of it.

If the transport clock is a little slower than the DAC clock it will after some considerable time generate a buffer underrun condition as the DAC will be taking data from the buffer faster than it's filling up. Conversely, if the transport clock is a little faster than the DAC clock there will eventually be a buffer overflow condition. If either of these conditions is reached or close to being reached (I clearly don't know the exact algorithm) the DAC64 goes into a failsafe mode where it starts to behave just like a normal DAC and links to the transport clock using a PLL.

Whilst music is playing, the clocks (transport and DAC) run totally independently of one another. When there's a gap of 8 seconds or more of silence the DAC resets the buffer pointers (ie, it waits until there's again roughly 4s of data to be read before starting to read from the buffer again). This is to avoid, as far as possible, buffer underrun or overflow situations.

Now jitter is a temporal phenomenon and it absolutely cannot be stored in a non-temporal medium like RAM memory so it (incoming jitter from the transport) is completely removed in this way.

The logical (and extreme to the point of ridiculous) extension of the DAC64 model of operation would be to have a 700Mb buffer that could store an entire CD. The transport would play the CD and the DAC would read it into its buffer in its entireity. At that point you could switch off the transport and let the DAC play out the CD. Surely no one believes that jitter (the varying time between 1s and 0s) is somehow stored in RAM?? RAM memory has no timebase so it can't store temporal information.

Clearly an 80 minute buffer would be ridiculous and totally impractical but the principle is the same whether the buffer is 4s or 80 minutes.

I can eject a playing CD and be putting it into its case whilst the DAC64s 4s buffer plays out. Just where is the jitter that the transport transmitted for those final 4 seconds supposed to have been stored? Perhaps Rob Watts deisgned a little extra buffer that stores the time interval between each pulse?

Yes, it should. Show me a noise free transport though and I'll show you pigs flying in the sky drawing a sled of naked virgins

Michael.

 

In which case it must be using the clock signal from the incoming SPDIF from the transport to designate the gaps between the 1's and 0's. This after all is all it's got to use, it would be mental to try and use it's own because of the aditional jitter it would create.

If you mean out if the buffer and into the DAC in the '64, then, of course, it would tell you the jitter!! In fact you'd only have to measure the clock itself for the clock jitter, and then from the clock into to the DAC to measure any additional actual jitter.
Just because it can eliminate the transports jitter (until buffer under/over run) does not mean it's not introducing it's own!!

Granted, what I was driving at is that at the incoming side (buffer filling) it will probably use a PLL based on the clock of the transport to fill the buffer (extracted from the incoming SPDIF). This is most likely unless it is just using signal state transition or somesuch to determine the incoming signal value. The jitter I was diving at was the possibility of the DAC64 clock being used to decode the transport signal and fill the buffer (as above). If this was so employed to drive (ok I won't say PLL, I'll say...) the counter for the buffer, it would introduce additional jitter, whereas if the transport clock is decoded from the stream, there would be no more additional jitter, and that in the transports's SPDIF signal itself wouldn't matter as it is only used to fill a buffer. I didn't know which clock it used for this which is why I mentioned the situation. Basically it doesn't diretly resample the input with it's own clock which is what I wondered.

Indeed by storing it in a buffer, it no longer operates in real time and can clock out at leisure the values in the buffer, thus eliminating any jitter from the incoming signal agreed.

This doesn't make up for errors on the incoming signal which are not jitter related, which is what I was driving at. I am not assuming that not all transports are perfect apart from varying jitter, which I think you are, and which is the circumstance that you're saying that the DAC64 must be transport independant. What I'm saying is not all transports are perfect because of the assumptions they make if / when they mis-read, in which case nothing downstream can be independant of it, including the DAC64. There's more to go wrong than jitter.

I think in my previous post shoiuld have said instead of "where the 1's and 0's are", but "what the 1's and 0's" are.

Cheers

 

OK, we're getting somewhere now. I basically agree with your post.

Totally agree, but the jitter it introduces would be independent of the transport used and as such would always have the same effect on the sound regardless.

Correct, that is what I'm saying. What other errors are there on the incoming signal which are not jitter related? AFAIK any old cheap transport can send the correct 1s and 0s and it's only jitter that can cause problems. I'd love to know what other errors there might be

Michael.

 

tim,
i think you misunderstand. the dac 64 uses the transport as a cd-rom drive. it just extracts the data sequentially. it doesn;t care if the in signal has 10psec or 5000 psec of jitter as each 16 bit word comes in in the correct order. it then waits for the buffer to fill up (4 seconds) and then clocks the data out using it;s own internal clock and overwrites the used data when it has to in a 'ring buffer' style. this way there is no possibility of the transports jitter performance effecting the dac 64's. i believe meridian do a similar thing in their 507 and 588 players too.
as for the interference of magic dbt rays between transport and dac well that's another discussion.
cheers


julian

 

Glad we managed to agree

Ok, well assuming that any competant designer can achieve somewhere near the the correct rise and fall times, then variations in this will only affect jitter, which means that the next biggest enemy by my estimations have got to be cable reflections.

Now we could argue that a proper line driver should overcome these, but they only tend to use a pitiful signal level and even that is only single ended ( most well thought out [i.e. competant] electrical digital signal transmissions that are designed to cover any distance are differential, and most pass though 0 Volts ).

Then when you add in cable reflections your digial bits can be blurred to the point where it can't tell the 1's from the 0's reliably any more. Impedance matching is supposed to sure this, but IME it's petty disappointing. The Pep Tech. P1A upsampler uses 0-5V as opposed to 0-0.5V, but you'd have to ask a designer which of these problems he was looking to cure by this.

Optical links are not immune to reflections either, it you run a glass optic, try a smear or isopropyl alcohol over the end of the fibre each end and see what happens to the sound for the 5 minutes before it evaporates. Not sure if it will work for the placcy ones because they have a different optical characteristic to start with, hopefully it wouldn't dissolve it!!

Cheers