Optical connection - inferior by default?

[P Floding]

Yes but...it is entirely possible to "remodel" the clock at the DAC input (ie right on the SPDIF socket) - see here
http://www.altmann.haan.de/jitter/en...ngc_navfr.html

A lot of things are possible.
But those claiming that SPDIF is a non-issue are not talking about what is possible, but what they think is the current state of things.

[Phil Leigh]

That's not entirely correct, though. That little gadget may attenuate jitter at the S/PDIF socket, but that's not the same as reducing jitter at the DAC where it matters. It's reducing jitter at the entry to the box that contains the DAC, which is not the same thing.

There will still be a PLL or VCXO circuit between the S/PDIF socket and the DAC chip itself. In fact, if the transport is well designed and has low output jitter, then the Altmann gadget is really just removing the jitter resulting from signal degradation in the cable.

The stuff on www.lessloss.com is, on the other hand, very accurate and a good read.

Well yes but...
In my setup, I have 2 coax cables and a TACT rcs between my sb3 and DAC - plenty of opportunity for jitter to be added to the low levels coming out of the SB3.

Also, the whole point is that not much jitter is added between the spdif socket and the DAC chip...the fact that there is a PLL en route is neither here nor there.

[Phil Leigh]

A lot of things are possible.
But those claiming that SPDIF is a non-issue are not talking about what is possible, but what they think is the current state of things.

I'm not claiming that!

[opaqueice]

It can. With a well implemented design it shouldn't. Someone else out there can tell us whether the good DAC chipes have an input buffer or not to avoid starvation. Basic voice communication codecs from 10 years ago did, so I am pretty sure DAC designers would take starvation issues into account.

I agree with your first statement, but an input buffer (which all DACs - including those in CD players - must have in order to function) does nothing in itself to resolve this problem. You still need to generate a clock from somewhere, and if you use the transitions in the input for that you´re still sensitive to jitter.

There are some easy but inconvenient ways to make a DAC that is completely insensitive to input jitter (for example buffer the entire input and then clock it out with a crystal), and some hard but convenient ways as well (see e.g. the Lavry whitepaper for the DAC10).

AndyC - sorry, ignore my earlier post.

[Phil Leigh]

I agree with your first statement, but an input buffer (which all DACs - including those in CD players - must have in order to function) does nothing in itself to resolve this problem. You still need to generate a clock from somewhere, and if you use the transitions in the input for that you´re still sensitive to jitter.

There are some easy but inconvenient ways to make a DAC that is completely insensitive to input jitter (for example buffer the entire input and then clock it out with a crystal), and some hard but convenient ways as well (see e.g. the Lavry whitepaper for the DAC10).

AndyC - sorry, ignore my earlier post.

Quite! - but that only works if you wordclock the DAC to the transport. Anything less is just a guess...

[P Floding]

Basic voice communication codecs from 10 years ago did, so I am pretty sure DAC designers would take starvation issues into account.

How old do you think the CD system is?
Getting close to 30 years now, I believe.

I know the problem at hand is EASILY solved, but you make the logical error of assuming that so has been done in all modern audio equipment. This is simply not true.

A one-box solution, like the SB, solves this problem, but it would be nice if SPDIF-usage was better implemented.

[Robin Bowes]

pablolie wrote:
> opaqueice;184700 Wrote:

>
> # I suggest you do some research before posting again
>
> Thanks. I suggest you provide useful information instead of just going
> ad hominem, because I haven't seen you make a point.

Let me make a point: you don't know what you're talking about.

SPDIF transmits digital data over an analogue transmission line.

The receiver must extract the clock signal from the signal it receives.

Now, in an ideal world, this wouldn't be a problem - the signal received
would have nice square edges and it would be easy to determine precisely
when each sample occurs and, hence, construct the clock signal.

However, because SPDIF is transmitted over an analogue path, the signal
received does *not* have square edges so it is possible that the clock
signal extracted from the stream is not 100% accurate.

As (several) others have pointed out, you obviously just don't get this.

Now, you can continue to point at the sky and scream "it's red" if you
like, but the fact is, you're wrong, and you need to go and read up on
the SPDIF specification and the inherent problems it has.

I have no more to say on the matter.

R.

[pablolie]

However, because SPDIF is transmitted over an analogue path, the signal
received does *not* have square edges so it is possible that the clock
signal extracted from the stream is not 100% accurate.
R.

i have not claimed the extracted signal is always accurate, or that errors aren't possible. but the fact the encoded signal is digital makes it more resilient, it's one of the whole friggin' advantages of digital data, foe heavens sake. that's telecom 101. that and nothing else has been my point.

since the analog signal quality can vary more without affecting the data integrity an ounce, as would be the case with a total analog transmission. that is and has been my point.

and not sure where you heard me claim the analog signal has or is supposed to have square edges. perfect little squares don't travel all too well over transmission paths. so they aren't exected. and if you're trying to claim you need a perfectly clean signal to extract clocking information... well, suit yourself.

i'll just say arrogance blends more credibly without blatant reading comprehension issues.

[seanadams]

Now, in an ideal world, this wouldn't be a problem - the signal received would have nice square edges and it would be easy to determine precisely when each sample occurs and, hence, construct the clock signal.

Not to go too far off the deep end here, but even if the transitions were infinitely steep and perfectly timed, it would be difficult to extract a clean clock. Due to zeroes having one fewer transition than ones, the receiving PLL will generate data-correlated jitter of its own as it drifts slightly between bits. Julian Dunn's "J-Test" paper describes how this works and how to reveal a receiver's worst-case behavior using a special square-wave signal, which is measured after the DAC. There are ways to minimize data correlated jitter by using an elaborate two-stage PLL, but even then it's still an analog circuit susceptible to noise. You could never do better than a local oscillator.

Of course, in an _ideal_ world we would have perfect PLLs, so I guess it would be a non-issue.

Incidentally, this test is what Stereophile and others use, and while it is a very clever test that can be performed without any exotic gear, it unfortunately has been applied far beyond its intended purpose. I've seen it used even to characterize devices that don't have s/pdif inputs! I suspect this is where the unfortunate, widely believed notion that "jitter is a number" comes from.

[opaqueice]

Not to go too far off the deep end here, but even if the transitions were infinitely steep and perfectly timed, it would be difficult to extract a clean clock. Due to zeroes having one fewer transition than ones, the receiving PLL will generate data-correlated jitter of its own as it drifts slightly between bits. Julian Dunn's "J-Test" paper describes how this works and how to reveal a receiver's worst-case behavior using a special square-wave signal, which is measured after the DAC. There are ways to minimize data correlated jitter by using an elaborate two-stage PLL, but even then it's still an analog circuit susceptible to noise. You could never do better than a local oscillator.

Interesting. S/PDIF really is flawed...

A question for those interested in getting as close as possible to audio perfection: it seems (for reasons discussed in this thread and many times before on this forum) that a SB or Transporter using its own DAC has a huge advantage over nearly any external DAC. Why do so few people here use it that way? It´s possible that with some very clever and complicated engineering an external DAC could overcome these problems, but why trust that it has when you have a much simpler and more elegant solution already available?