[Rob Watts]

Alright, how are you recovering the clock from the spdif signal?

I note you wrote this yourself: "Because video is very important to me, I wanted a system that would eliminate the PLL SQ problems, and so I developed the DPLL system that you can find on all my DAC's - and it took many years to perfect." As far as I am aware, DPLL is still PLL.

Also, if I am wrong, you can tell me the correct answer. Not sure if this type of response is good marketing...I suppose some appreciate this communication style.

So firstly there is no master clock to be recovered from the SPDIF - but I digitally convert the SPDIF format into a parallel I2s like format - that is word clock, data left and data right. The word clock is extracted directly from the pre-amble, this word clock extraction only works on the fixed pre-amble so has no possibility of data related jitter, unlike using a conventional PLL based clock extraction, which relies on all transitions, pre-amble and data.

The extracted word clock then is fed to the DPLL. I should not call it a DPLL, (DFLL is more appropriate term) as phase locking is only applied initially; once initial lock is obtained, it works upon frequency only and is frequency locked to the incoming word clock - so the phase (and hence jitter) of the incoming word clock has zero influence on the generated word clock, which is generated from the local low jitter 104.25MHz fixed frequency oscillator. The DPLL ensures that the generated word clock is frequency locked to the incoming word clock, and it has a time constant of many seconds.

Meanwhile the data is fed into a micro buffer, and the data is read out from the buffer via the generated word clock, which is synchronous to the 104.25MHz low jitter fixed clock.

But I can talk as much technicalities as I like - ultimately it does not matter. The fact is that using my MSI lap-top I got identical sound quality from using optical SPDIF as using USB with Dave. USB of course is asynchronous, the data is fed to the DAC with an integer count of the 104.25 MHz low jitter clock, so no clock generation is done at all, nor any conversions from SPDIF to parallel data either. So I know the DPLL system is innately transparent. This does not mean that all USB sources sound the same as optical, as the galvanic isolation on the USB is not perfect - some RF noise can leak into the DACs ground plane from noisy USB sources via the 2pF isolation capacitance on the USB interface. But you can treat the optical input as the SQ reference, with USB either sounding identical to optical or worse, depending upon the cables and the source and how much RF noise is fed into the DAC.

 

[The Jester]

So there’s no possibility of USB sounding any better than optical unless the optical output of the source is inferior to its USB implementation, leaving the only reason for using a USB input down to the 96k (sometimes 192k) limit of optical cables ?

 

[MvRBE10]

I always have 192k (not sometimes) on my optical input, whatever cable i use. I had the 192k when i used mt node2i and same onnthe aurender n10 now. Maybe you have a problem on your streamer side.

 

[The Jester]

No problems here, only need 16/44.1 from CD transport and server, apart from the odd 24/96 download.

 

[JGoose]

Was over on another forum and saw a post from a new shop about a Chord Electronics Open day they are running. One line stood out from the rest:

"Chord Electronics will be launching a brand-new Ultima Product at the Open Day". The Ultima series only seems to be missing one thing an Ultima Source/DAC! It's got to be right?

Thought I would come to share the news here and see what you guys think. I know Rob Watts likes to join in the discussion, has there been any mention?

 

[skootb]

Not sure if this type of response is good marketing...I suppose some appreciate this communication style.

Being able to directly communicate with a product's designer seems like great marketing to me

 

[Jawed]

Was over on another forum and saw a post from a new shop about a Chord Electronics Open day they are running. One line stood out from the rest:

"Chord Electronics will be launching a brand-new Ultima Product at the Open Day".

Ultima 4? 500W per channel stereo amp in a "double height" chassis?

 

[adrianm]

Was over on another forum and saw a post from a new shop about a Chord Electronics Open day they are running. One line stood out from the rest:

"Chord Electronics will be launching a brand-new Ultima Product at the Open Day". The Ultima series only seems to be missing one thing an Ultima Source/DAC! It's got to be right?

Thought I would come to share the news here and see what you guys think. I know Rob Watts likes to join in the discussion, has there been any mention?

The Ultima series is an amplifier product line. There's really no chance it will be a dac. My hope and best bet would be a new headphone amplifier, though it might just be more of the same.

 

[Torq]

I have my doubts if multi stranded optical is better than single ones.

Ok thinner strands shorten the inner reflected travel distance of the signal forcing a more straight line.. but on the other side the signal arrives a multitude of times slightly different in time with each strand that may confuse the receiver side.

In practice, this is a non-issue.

The principal cause of jitter in TOSLINK is the rise/fall time of the optical pulses, which is a factor of the emitter and receiver.

Typical times here are 30-40ns.

That's vs. the 80ns pulse duration of a 192 kHz TOSLINK stream (the signaling speed for which varies only by sample rate, not bit-depth).

If you took a cheap glass (unclad fibers) multi-strand cable, 10m long (the practical limit here), and measured the time-of-flight for two photons, one following a 100% straight path, the other taking the longest possible path (i.e. the maximum degree of bending and internal reflection) then the difference between the two would be 25ns. That, of course, is a massively exaggerated, worst-case, example, and cannot happen in a real cable.

If you do the same thing with a better multi-strand glass cable, using clad fibers, the difference drops to 3ns.

Curiously, those numbers do not actually change meaningfully with a single-strand cable, as the principal cause of internal reflections (i.e. a non-straight path for every photon) is that the light source is not well aligned to the fiber and the light itself is incoherent. The photons are already entering the fiber(s) at significantly varying angles, so they all take different paths "bouncing" through that single fiber anyway ... even if it is 100% straight.

---

That's a long way of saying that, while the differences you cite do exist - in practical terms they're so small in effect as to be completely dwarfed by other issues in the system and have no practical, measurable, effect on the actual clock/jitter. Other issue with the system effectively mask them.

 

[atya35mm]

quick question all, can’t seem to find this info searching the thread but pretty sure it was mentioned here before, but can I find out what is the recommended db volume for normal RCA output of 2v out of Dave with M scaler? I understand M scaler reduce volume by -3db, so would leaving Dave at -3db technically mean -6db with M scaler already doing -3db. And is -6db = 2v ish?

 

[genefruit]

quick question all, can’t seem to find this info searching the thread but pretty sure it was mentioned here before, but can I find out what is the recommended db volume for normal RCA output of 2v out of Dave with M scaler? I understand M scaler reduce volume by -3db, so would leaving Dave at -3db technically mean -6db with M scaler already doing -3db. And is -6db = 2v ish?

Based on a chart previously posted but I don’t have the direct link,
2V DAVE = -7
2V HMS&DAVE =-4.

 

[atya35mm]

Based on a chart previously posted but I don’t have the direct link,
2V DAVE = -7
2V HMS&DAVE =-4.

Perfect! Thank you good sir!

 

[Reactcore]

In practice, this is a non-issue.

The principal cause of jitter in TOSLINK is the rise/fall time of the optical pulses, which is a factor of the emitter and receiver.

Typical times here are 30-40ns.

That's vs. the 80ns pulse duration of a 192 kHz TOSLINK stream (the signaling speed for which varies only by sample rate, not bit-depth).

If you took a cheap glass (unclad fibers) multi-strand cable, 10m long (the practical limit here), and measured the time-of-flight for two photons, one following a 100% straight path, the other taking the longest possible path (i.e. the maximum degree of bending and internal reflection) then the difference between the two would be 25ns. That, of course, is a massively exaggerated, worst-case, example, and cannot happen in a real cable.

If you do the same thing with a better multi-strand glass cable, using clad fibers, the difference drops to 3ns.

Curiously, those numbers do not actually change meaningfully with a single-strand cable, as the principal cause of internal reflections (i.e. a non-straight path for every photon) is that the light source is not well aligned to the fiber and the light itself is incoherent. The photons are already entering the fiber(s) at significantly varying angles, so they all take different paths "bouncing" through that single fiber anyway ... even if it is 100% straight.

---

That's a long way of saying that, while the differences you cite do exist - in practical terms they're so small in effect as to be completely dwarfed by other issues in the system and have no practical, measurable, effect on the actual clock/jitter. Other issue with the system effectively mask them.

With confusing the receiver im not pointing to jitter but the receiver mistaking 1's for 0's or visa versa cause of the longer 'light on' times due to overlap of the strands light pulse arrivals.



With higher sample rates the overall pulses time is shorter making the overlap error of longer on times more relevant. 192k seems to be on the edge of the tolerance

 

[sm60]

With confusing the receiver im not pointing to jitter but the receiver mistaking 1's for 0's or visa versa cause of the longer 'light on' times due to overlap of the strands light pulse arrivals.



With higher sample rates the overall pulses time is shorter making the overlap error of longer on times more relevant. 192k seems to be on the edge of the tolerance

I find it hard to get motivated by these arcane discussions about whether optical is better than USB or SPDIF or whatever. Any of these interfaces has a million times lower distortion than the lowest distortion headphone or speaker on the planet. When I stream a high Rez album on Qobuz, it could be traveling thousands of miles through hundreds of links, who knows how many transmitters are involved. Yet barring a technical glitch in my local internet, I get the original file intact bit by bit perfect. End of story. If you want to solve the really hard problems in high fidelity, focus on the headphone or speaker design problem. That’s where the challenges lie. Headphones are so bad a transducer and distort so badly, it’s a joke. On control your room resonances. Trying to minimize absolutely trivial amounts of digital noise on a 1 meter optical or USB link is so silly, all my CS and ECE colleagues will laugh themselves to death over it. Heck, we can receive beautiful pristine images from the James Webb telescope that is now 1 million miles away from Earth. Heck, we can detect two galaxies colliding billions of light years away releasing more energy in one collision than all the observable matter in the universe using LIGO detectors. The engineering challenges here are so formidable that they took decades to solve to make sure the measurements are not corrupted by noise. Worrying over digital noise in a 1 meter cable is really wasting time over an absolute triviality.

Just my $0.02! Feel free to ignore me and continue this discussion.

 

[Torq]

With confusing the receiver im not pointing to jitter but the receiver mistaking 1's for 0's or visa versa cause of the longer 'light on' times due to overlap of the strands light pulse arrivals.

The difference in maximum potential (i.e. worst-case-scenario) signal ToF differential within a multi-strand cable is insufficient to cause this. The typical scenario is an order of magnitude better than that. It also does not meaningfully change from a single-strand cable vs. multi-stand - assuming similar aggregate fiber diameter and materials. Typically multi-strand fibers are clad, which dramatically improves their RI vs. unclad, further reducing the potential delta.

In practical implementations, it just doesn't matter.

With higher sample rates the overall pulses time is shorter making the overlap error of longer on times more relevant. 192k seems to be on the edge of the tolerance

192 kHz is double the original sample rate for the TOSLINK spec. It is at the edges of tolerance because it needs 80ns pulses for the S/PDIF subframes, and the typical TOSLINK emitter/receiver has a rise/fall time of 30-40ns (which yields a 50% tolerance for a 96 kHz sample rate). For reliable discrimination you need the rise/fall time to be half (ideally less) of the pulse duration.

A marginal emitter/receiver (or a bad pairing - i.e. technically suitable devices, but each operating at the wrong ends of their performance tolerance/rating) may not rise/fall fast enough to maintain clean 80ns pulses. When this happens, the connection fails ... rather than 0s or 1s being misinterpreted.

You'll usually see more variation in the performance of a TOSLINK connection based on how well aligned and tolerance the sockets are than you will in the same connection using a multi-strand vs. single-strand cable.