SPDIF and Coax - is it the same?

[unsleepable]

One of the interesting things as you get old, is how knowledge gained by older generations is somehow considered of less value than the current crop of researchers. So, running through your points (in a slightly different order):

But what is with age in this forum? While I always respect experience, I find that this and knowledge are not always the same thing. And your knowledge seems to be rather outdated in this matter.

I am starting to think I may have a hobby not appropriate for my age…

Just because the paper was written in '92 does not make it any less valid. Ampere, Volta and Ohm were all born in the 1700s, their analysis is still going strong.

Of course that a paper written in 1992 versing about errors when detecting electrical and optical signal changes is not relevant nowadays. This paper is not about immutable principles, but about the state of the technology when it was written. Optical communications have advanced enormously in the last 20 years, and currently optical fibres are able to carry several orders more data and over longer distances than they were at the time when TOSLINK was specified. Even current domestic gear implementing TOSLINK ports easily supersede the TOSLINK specification and carry data in longer distances, just because the parts used are more advanced. Your claim that an electrical signal is "more exact" than an optical one is absurd.

You are confusing data rate with the bandwidth required to preserve a decent pulse shape. Instead of thinking of the clock as a digital signal, think of it as an analogue waveform whose risetime needs to be protected. To keep a passable edge, the link needs to be able to carry at least the first 3 or 4 odd harmonics.

Bandwidth in a data link is what it is. And if you want to give it another meaning in this context that's fine with me—but lay your own definition on the table so that I can understand you, because I don't. As for the standard definition, the bandwidth carried by S/PDIF on optical and coaxial cables is simply the same.

In biphase mark encoding, a '0' has a transition at the start of a bit period, a '1' has an additional transition in the middle of a bit period. A repeated '1111111' will be a square wave with twice the frequency of '000000'.

Correct, and what does it matter? The data rate is constant. You said before that "This means that '1111' will tend to slow the PLL clock down slightly, '0000' will speed it up slightly." And again, this is not the case. Both transmissions take eight cycles clearly marked by the sender—whether optical or coaxial.

You are confusing bit errors in the data with derived clock phase errors. It is not a question of when the bit is sampled, it is a question of when the flywheel in the phase locked loop gets its kick from the clock transition detection circuitry - this point differs for '1's and '0's, hence the introduction of phase jitter.

I am not confusing this. It doesn't even make sense to talk about transmission errors in domestic TOSLINK connections.

Anyways, don't be so naïve as to think that a receiver is going to read a 1 when it detects the signal change within the sample distance, and a 0 on the signal change at the end of the cell. I think it would more difficult to program this than to do it well.

I also fail to see how this is any different for optical than for coaxial.

By definition, every link is band limited, and this problem is still real today. The standard toslink chipset has relatively poor bandwdith, and does introduce phase jitter. Whether it is audible or not depends on the magnitude and spectrum of the jitter, and what the DAC does with it.

If you think that your previous comments prove this point, I'm afraid they don't.

The only difference between electrical and optical S/PDIF transmissions is whether voltage or light is used. All the rest is the same, so apart from better or worse implementations, any differences could only be attributed to whether one allows to detect signal changes more exactly than the other. And as I said before, assuming that an electrical signal can be read more exactly than an optical one is simply absurd.

 

[SteveR750]

This is all very nice, but this ****** waving isn't answering the OP, or a couple of other questions posted within the thread.

 

[andyjm]

This is all very nice, but this ****** waving isn't answering the OP, or a couple of other questions posted within the thread.

I answered the other questions further up the thread.

I am trying to explain to unsleepable why a paper written 22 years ago shows why toslink can sound worse than coax, and why the quality of a toslink implementation matters. I have clearly failed.

My guess is that unsleepable has digital experience, but not analogue. Bizarre though it sounds, digital is analogue underneath.

 

[SteveR750]

Not this one you didn't!

Andy, is there any difference in the way the data is streamed to the DAC, i.e. async, adaptive? I'm guessing that a DAC that send timing data to the device will therefore be somewhat dependent on cable quality, whereas adaptive / data reclocked in the DAC is far less so?

One thing I don't understand, is why DACs don't simply buffer a chunk of data, and stream from that source? At the moment, I have set J River to play from the memory, surely a DAC could include at little extra cost a couple of Gbs worth of SSD from which to stream each file? This is effectively what is happening in the PC -> internal soundcard?

 

[andyjm]

Not this one you didn't!

Andy, is there any difference in the way the data is streamed to the DAC, i.e. async, adaptive? I'm guessing that a DAC that send timing data to the device will therefore be somewhat dependent on cable quality, whereas adaptive / data reclocked in the DAC is far less so?

One thing I don't understand, is why DACs don't simply buffer a chunk of data, and stream from that source? At the moment, I have set J River to play from the memory, surely a DAC could include at little extra cost a couple of Gbs worth of SSD from which to stream each file? This is effectively what is happening in the PC -> internal soundcard?

I incorporated part of the answer in another response, but not very well. Here goes again.

A DAC that uses its own local clock will be independent of timing issues caused by trying to recover the clock from the incoming S/PDIF stream and therefore immune to any impact of the cable or the link or the quality of the streamer or cdp clock.

The problem this creates is trying to keep the player and incoming data in step. There are a few ways around it. You could read the data into a buffer as you suggest ( some players do) at the expense of having to wait a bit after pressing play for the buffer to fill. You could employ an async re sampling technique ( some players do this). The best solution IMO is to be able to control the rate at which data is sent to the DAC. This needs a bi directional link between DAC and data source, S/PDIF is one way only. Early solutions used a separate word clock sent by the DAC to the data source, a better solution is the industry standard USB which is bidirectional by design.

 

[unsleepable]

[…]

I am trying to explain to unsleepable why a paper written 22 years ago shows why toslink can sound worse than coax, and why the quality of a toslink implementation matters. I have clearly failed.

My guess is that unsleepable has digital experience, but not analogue. Bizarre though it sounds, digital is analogue underneath.

Well, the argument you made wasn't exactly compelling. And knowing the hard stance you usually take on cables, it's rather amusing to see the stuff you then believe in.

 

[davedotco]

Not this one you didn't!

Andy, is there any difference in the way the data is streamed to the DAC, i.e. async, adaptive? I'm guessing that a DAC that send timing data to the device will therefore be somewhat dependent on cable quality, whereas adaptive / data reclocked in the DAC is far less so?

One thing I don't understand, is why DACs don't simply buffer a chunk of data, and stream from that source? At the moment, I have set J River to play from the memory, surely a DAC could include at little extra cost a couple of Gbs worth of SSD from which to stream each file? This is effectively what is happening in the PC -> internal soundcard?

I incorporated part of the answer in another response, but not very well. Here goes again.

A DAC that uses its own local clock will be independent of timing issues caused by trying to recover the clock from the incoming S/PDIF stream and therefore immune to any impact of the cable or the link or the quality of the streamer or cdp clock.

The problem this creates is trying to keep the player and incoming data in step. There are a few ways around it. You could read the data into a buffer as you suggest ( some players do) at the expense of having to wait a bit after pressing play for the buffer to fill. You could employ an async re sampling technique ( some players do this). The best solution IMO is to be able to control the rate at which data is sent to the DAC. This needs a bi directional link between DAC and data source, S/PDIF is one way only. Early solutions used a separate word clock sent by the DAC to the data source, a better solution is the industry standard USB which is bidirectional by design.

Just to be clear, does this mean that in a asyncronous usb implementation, the clock in the dac controls the rate at which the data is sent from the computer? (in laymans terms anyway)

Is this really what 'asyncronous' means?

 

[SteveR750]

Same question too Dave.

i'm assuming that this bi directional mode is the one used with a USB 2 ASIO driver.

BTW I discussed this with the poeple of Hegel the other day, and am waiting to hear from them how their sampling / data feed works. I have three choices in the driver settings - Kernel Streaming, Direct Sound, and WASAPI. J River recommends WASAPI-Event Style wherever possible, so I have used WASAPI. I suspect Kernel Streaming uses the Windows K mixer, and therefore is resampled / mixed with system sounds etc before being streamed to the DAC.