Optical connection - inferior by default?

[Robin Bowes]

pablolie wrote:

> It's *data*. Data integrity is the key. It does not matter of the
> signal gets somewhat distorted. That's actually one of the key
> advantages of digital interfaces: you don't have to worry as much over
> signal integrity. It's no misconception at all. An ugly bit is still a
> bit.

I'm afraid you're wrong.

I suggest you read up on how SPDIF works and the potential weaknesses
inherent in its design.

R.

[pablolie]

pablolie wrote:

> It's *data*. Data integrity is the key. It does not matter of the
> signal gets somewhat distorted. That's actually one of the key
> advantages of digital interfaces: you don't have to worry as much over
> signal integrity. It's no misconception at all. An ugly bit is still a
> bit.

I'm afraid you're wrong.

I suggest you read up on how SPDIF works and the potential weaknesses
inherent in its design.

R.

SPDIF is BMC encoded, and therefore *digital*. Please tell us what's wrong about that. And an advantage of digital has and always will be the fact signal quality issues become relative, since regeneration of the original data is straight forward.

Consequently, the quality of the phyiscal signal has to be quite compromised for a bit error to occur, and until a bit error occurs the signal issues are immaterial. Truly. You seem to disagree about the probability of that happening, but to argue over the fact that the data is encoded digitally is lunacy.

Of course there will always be analog effects at the signal transmission level, and those have been discussed in this forum when the merits of RCA and Toslink were compared. That's where the signal quality discussion kicks in.

Other than that I truly don't know what analog effect you could be talking about: we ought to simply be worried whether your 20 bit (or 24) audio data stream emerges identical on the remote end as it is presented to the DAC subystem. The fear seemed to be the data goes into the DAC subsystem with additional jitter if the Toslink connector is used. You seem to be introducing a data integrity element that as far as I have seen no one has brought up, since the interface is quite resilient at that level, irrespective of the interface type used for transmission.

[seanadams]

SPDIF is BMC encoded, and therefore *digital*.

Absolutely 100% wrong.

The _TIMING_ information which is carried by s/pdif is an analog signal in the truest sense, not just "on the wire" but from end to end. Are you really questioning that?

[pablolie]

Absolutely 100% wrong.

The _TIMING_ information which is carried by s/pdif is an analog signal in the truest sense, not just "on the wire" but from end to end. Are you really questioning that?

Biphase Mark Coding is encoding for *digital* data, plus the frequency of the clock is twice the frequency of the original signal. The result is that at the physical level it's not about 0 and 1, but about even simpler polarity changes, which makes data *and* clock *easier* to recover. I never claimed there are no analog elements at the transmission layer - my point is that analog signal integrity is less critical for sound purity than with "pure" analogue signal transmission. Are you questioning that?

Truly don't know what we're arguing about here? Are you claiming digital data transported via SPDIF is prone to bit errors? Are we back to the jitter issue, which you labeled immaterial yourself? Or are you saying that signal integrity is just as critical for purity in the pure analog as it is in the digital domain, as the person I was countering seemed to maintain?

I think the OSI layers are getting mixed up in there discussions. At the lowest physical layer, there'll always be analog effects. but the interface to the "data link layer" is purely digital, and as long as it presents the same digital information for the higher layers to process whatever signal distortion at the physical analog level does not matter an ounce provided everything is properly contained in its respective module. Easier said in theory than done in practise.

[AndyC_772]

What a lovely thread - it has passion, enthusiasm and complete BS all rolled into one Let me try to clear some of it up; apologies to those of you for whom this is all basic stuff, but I've yet to see a good explanation of signal integrity in an audiophile forum, and there's an awful lot of vagueness and pedantry around with remarkably little science to back it up.

With any digital data link, there are always two aspects to consider: the data itself, and the associated clock. Let's consider them separately for a moment.

The data is the easy bit. It's just ones and zeroes, and as long as there isn't so much noise on the wire that they actually get misinterpreted, it's easy to reliably recover exactly what was transmitted. It doesn't matter whether they originally came from a CD, or a file on a hard disc, or over an Ethernet or wireless connection.

Then there's the clock, which is more complicated. In some communications systems, the clock is carried on a separate wire, and the receiver samples the data whenever the clock changes from low to high or from high to low. If all you're doing is storing the data in memory or forwarding it on to another device, that's all there is to it. As long as the clock transitions line up with the data bits, the link works. Zero degradation.

In many modern systems (Ethernet, USB, S/PDIF), no separate clock wire is used. Instead the clock is recovered by looking at the timing of transitions in the data. In the case of something like Ethernet, where all you care about is getting the data from A to B reliably, this also works fine.

The problem comes when you have to start caring about not just getting the bits from A to B, but also about exactly when they arrive at their destination. This is the problem with S/PDIF - you need to play the music at the same rate it comes in.

A CD is sampled at 44.1kHz. But, no oscillator in the world (and certainly, no oscillator in your hi-fi) ticks at precisely that speed. Standard tolerance on a quartz crystal is +/-50 parts per million, which is no problem in itself - you can't hear the difference if you CDs are played back at 44.1002205kHz instead.

However, say your DAC were running 50ppm fast and your CD transport (or whatever) were 50ppm slow. About 4 times per second the DAC won't have a sample to play, and you might hear this as a click. Not very hi-fi, I'm sure you'd agree. So, there has to be a mechanism to ensure that the clock in the DAC runs at precisely the same speed as the one in the source component. Because S/PDIF is unidirectional - it only provides a path from source to DAC and not the other way round - it has to be this way.

When music is digitised, samples are taken at precisely determined intervals by very expensive studio equipment, and so to reproduce the original signal as accurately as possible, the output from the DAC has to be updated equally precisely, so that the time interval between successive samples is the same as it was originally. Variation in this period between samples is what we all know and love as jitter.

The only place this jitter matters is at the DAC chip itself. In a device like a Squeezebox, big bursts of data are sent over the network into a buffer memory, then it's broken into smaller packets and stored in a FIFO (first in, first out) buffer by the CPU, and finally clocked into the DAC a bit at a time at regular intervals. It's only at the point where the last bit is clocked in and the DAC updates that jitter makes any difference whatsoever. If an external DAC is in use, it's only the clock pulse that causes that DAC chip to update that matters. Jitter elsewhere is basically a non-issue.

What does this have to do with S/PDIF?

This is all down to implementation. For the reasons explained above, a circuit in the DAC has to recover the clock from the S/PDIF signal and, from this, generate a clock to the DAC which is synchronised and yet has the least amount of jitter possible. Typically this is done with a circuit called a Phase-Locked Loop or PLL, and although they're very good at rejecting jitter, they're not perfect. The more that's fed in, the more comes out.

So, jitter on the S/PDIF link can lead to jitter at the DAC input, which in turn can affect the sound. That's why all S/PDIF links are not equal

The ideal is to have the master clock located in the DAC, not the source. Then you can have a high quality, stable oscillator right by the DAC chip itself, where it matters. But S/PDIF doesn't allow for this, because there's no way for the DAC to control the rate at which data is transferred. Bidirectional links like Ethernet, USB and Firewire get around this problem. (I have a USB connected headphone amp at work with its own built-in DAC. It sounds wonderful!).

Optical vs coax? Both can give rise to unwanted jitter. With an optical cable, the signal from the phototransistor in the receiver (which is what matters) is fairly small and its rise/fall time isn't instantaneous - so there's uncertainty as to exactly when the transitions between 1 and 0 have occurred. On the other hand, coax can have sharper edges which are easier to time between. But it can also pick up RF noise, which adds uncertainty back in, and there are a whole host of transmission line effects which I won't go into now.

Hope that helps a bit

Andy

[pablolie]

since this is where this subthread originated, just step by step...

# It's digital data, but it's sent over an analogue transmission
# path. The
# 1s and 0s are converted to different voltages and the
# resulting signal
# sent down the cable.

yes, agreed. bmc is not about 0 and 1, it´s about positive and negative polarity. biphase, and only two signal states the receiver cares about. thus the name BMC.

the question is, what's the motivation for that. you make claim it makes it more prone to problems? quite the contrary.

# If the signal on the cable gets distorted in any way then the
# signal
# produced by the receiver may not match that fed into the
# transmitter.

and the whole point is that that does not matter when it comes to recovering the original data. the signal may look different, and that's acknowledged and accounted for. the exact same data with the exact same clocking information arrives, though, and the different packaging does not make a difference when it comes to data integrity -and in our case digitally encoded audio data- which is all the digital domain´-which processes the data- cares about.

have you truly claimed analog transmission elements that do *not* affect SPDIF bit integrity still have an effect? i could imagine reasons why that´s that case in a real world implementation, but that has little to do with the SPDIF protocols...

[pablolie]

...
Hope that helps a bit

Andy

This thread is over. You put it perfectly.

[AndyC_772]

ps. I can tell the difference between a poor digital transport connected via an optical lead, and a good one connected by coax. Last year I replaced my high quality (but early and buggy) DVD player with a cheap recorder. I was convinced that they'd sound identical played through the same external DAC.

It took me about a week to work out that I just wasn't enjoying the music any more. The soundstage was flat and it was hard to pick out individual instruments.

One used, high-end universal player from Ebay later, normal service is resumed.

The Squeezebox sounds pretty good too

[AndyC_772]

This thread is over. You put it perfectly.

(disclaimer: I'm a professional electronic engineer specialising in communications systems... so I ought to know what I'm talking about!)

[seanadams]

This is so well understood and so easily observed that I just don't know what to say. It's as if you're pointing at the sky screaming "it's red" and expecting a meaningful argument. I wonder if you're just trolling, and the joke is on me.

Also, my comments in the other thread about the audibility of small levels of incremental jitter do not make the phenomenon cease to exist. But that was a nice try.