Toslink cables

[Chester]

Jenving Supra Toslink guaranteed 32 bit 384 kHz capacity, in lengths up to 15 meters:

http://www.jenving.com/products/view/zac-toslink-optical-15m-1003100193

I always wondered if it works properly...

If the dac reclocks the signal, jitter should be of no concern, I guess.

The Supra Toslink is my most expensive toslink cable and worst performing. For the reason mentioned earlier....it is too heavy and the connection dislodges frequently. It sits in my hifi cupboard graveyard keeping the Audioquest Jitterbugs company

 

[SIY]

What does badly implemented means?

Benchmark dac2 has two optical inputs.

one of us was sitting at sweetspot with blindfold, the other randomly changed the optical input.

8 philips were selected at 10.

Your description is nothing like what happens with digital data transmission faults.

There’s a lot of ways to screw up controls, so I’m not prone to speculate which one was yours.

 

[Sparky]

This is going to sound really dumb but please entertain me.
I don't understand "clocks" in audio and won't pretend to know about "jitter" and the like so can someone explain the process of audio transfer from a TV to a DAC or pre-amp via optical.
So, a modern TV is receiving a signal in multi-channel which then routes the signal via optical to a suitable pre-amp (DAC).
I assume the TV itself decodes and downmixes the multi-channel audio to stereo and pass it via optical.
The DAC receives the signal, converts it to analogue and passes it to the speakers (assuming passive speakers).

Which device is in control here? Which device is the "clock" and why does that matter?

What if, like me, you have active speakers? Which device is the "clock" in that instance and, again, why does it matter?

 

[MRC01]

Transferring digital audio is like transferring any other kind of digital data. It can be push or pull. By "push" I mean the source sends the data to the destination, which receives and interprets it. By "pull" I mean the destination requests data from the source, which means the source sends chunks of data "on demand" - when the source asks for it.

With digital audio, the data consists of amplitude samples, so the rate at which they are sent is important. That's what the clock is for: to ensure the samples are interpreted at the correct rate. For example CD is 44,100 samples per second which is 1/44100 = 2.268e-5 second spacing between samples.

In the "push" scenario, the source uses its own clock to ensure it sends samples at this rate. The destination can buffer the samples and use its own clock to space them evenly. But, if the source & destination clocks are not perfectly in sync, if one runs slightly faster or slower than the other, the buffer will eventually over or under flow and you'll get a glitch. The best the destination can do is buffer the samples and use its own clock to compute the average rate at which samples are arriving and reclock / respace them using that average. Its own clock might not agree this average is correct (e.g. 2.268e-5 gap between samples for 44100 rate), but it must use whatever rate the source is providing because it doesn't control the rate. At least this buffering and re-clocking will correct any sample timing differences caused during transmission.

In the "pull" scenario, the destination uses its own clock to determine the rate or spacing of samples. It requests chunks or batches of samples from the source, according to its own (the destination's) clock. For example, with CD audio it could ask for 44100 samples every second, or 22,050 samples every half second, or whatever. Of course, it will ask for samples ahead of when it needs them, store them in a buffer until needed, and read from its buffer at the exact rate determined by its own clock. In this case the source doesn't even need a clock, it simply transmits chunks or batches of samples on demand.

This is an oversimplification but I hope it conveys the general idea...

 

[Sal1950]

Perhaps one of them can do 24/192 on specific DACs and the other one may have issues at that speed which is just above what it can do.

According to DH Labs, their Glass Master Optical Cable supports 24/192. Benchmark DAC2 HGC don’t support 24/192 via optical toslink but my network transport supported 24/192 output via toslink.

24/192 IME has been temperamental over Toslink. My Emotiva DC-1 DAC has no problem doing 192 from my Gigabyte motherboard's port if the cable is kept short (like 1meter) but if I go too much longer it just won't lock to the data stream at all. I just use USB now that I solved my ground loop hum with it.

 

[eyes-on-you]

24/192 IME has been temperamental over Toslink. My Emotiva DC-1 DAC has no problem doing 192 from my Gigabyte motherboard's port if the cable is kept short (like 1meter) but if I go too much longer it just won't lock to the data stream at all. I just use USB now that I solved my ground loop hum with it.

Shouldn't the opposite be true?

Optical connection solves the ground loop problem.

 

[Sparky]

Transferring digital audio is like transferring any other kind of digital data. It can be push or pull. By "push" I mean the source sends the data to the destination, which receives and interprets it. By "pull" I mean the destination requests data from the source, which means the source sends chunks of data "on demand" - when the source asks for it.

With digital audio, the data consists of amplitude samples, so the rate at which they are sent is important. That's what the clock is for: to ensure the samples are interpreted at the correct rate. For example CD is 44,100 samples per second which is 1/44100 = 2.268e-5 second spacing between samples.

In the "push" scenario, the source uses its own clock to ensure it sends samples at this rate. The destination can buffer the samples and use its own clock to space them evenly. But, if the source & destination clocks are not perfectly in sync, if one runs slightly faster or slower than the other, the buffer will eventually over or under flow and you'll get a glitch. The best the destination can do is buffer the samples and use its own clock to compute the average rate at which samples are arriving and reclock / respace them using that average. Its own clock might not agree this average is correct (e.g. 2.268e-5 gap between samples for 44100 rate), but it must use whatever rate the source is providing because it doesn't control the rate. At least this buffering and re-clocking will correct any sample timing differences caused during transmission.

In the "pull" scenario, the destination uses its own clock to determine the rate or spacing of samples. It requests chunks or batches of samples from the source, according to its own (the destination's) clock. For example, with CD audio it could ask for 44100 samples every second, or 22,050 samples every half second, or whatever. Of course, it will ask for samples ahead of when it needs them, store them in a buffer until needed, and read from its buffer at the exact rate determined by its own clock. In this case the source doesn't even need a clock, it simply transmits chunks or batches of samples on demand.

This is an oversimplification but I hope it conveys the general idea...

Thank you for the explanation. That really helps me understand how it works.

I have to make an assumption that the clock in the TV (or any TV for that matter) will be grossly inferior to the clock in my minidsp SHD.

Anyway, thanks again for taking the time to explain.

 

[MRC01]

24/192 IME has been temperamental over Toslink. ...

Toslink has bandwidth limited by the composition and length of the cable, among other factors. 3 bytes per sample (24 bits) times 192,000 samples per second, times 2 (stereo) = 1.15 Mbytes / second. When you add the SPDIF data frame overhead, it's even more. With many toslink cables, this exceeds the bandwidth and it doesn't work.

 

[Sal1950]

Shouldn't the opposite be true?

Optical connection solves the ground loop problem.

You would be correct if you read my post more closely.

 

[preload]

I know of no provable advantages it has over spdif/AES or USB, other than the overblown ground isolation myth, usually easily curable in systems with metallic interconnects. Me? I am a very happy USB user, with no dodads or gizmos in the signal path. I just use a properly isolated DAC.

It's funny that you mention that. I was getting horrible ground loop noise when connecting the line out of my Denon AVR3600h to my Kef LSX line in. So I dropped in a RME ADC to convert the line out to toslink and send it to the optical input on the Kef. Noise eliminated!

 

[solderdude]

According to DH Labs, their Glass Master Optical Cable supports 24/192. Benchmark DAC2 HGC don’t support 24/192 via optical toslink but my network transport supported 24/192 output via toslink.

I have no idea about Philips POF but i think it supports only 24/96.

The cable can probably support DXD multichannel.
Even the transmitters can probably reach it.
The bottleneck is the receiver not the cable.

 

[solderdude]

I would like also to mention; When I hold the phone flash at one end of the Glass Master toslink, I see little black spots in the light coming from the other end. In addition, the glass surfaces seemed rough to my eye.

I tried to clean it but i couldn’t.

There is a homogeneous light beam at philips POF.

Yes, that's normal. I assume they just use a bunch of 62.5 micron fibers (which are 125 micron in diameter + cladding and a plastic 'buffer/coating' makes them 250u) so only a small part of the total bunch of F.O. cable conducts light where in the POF the whole diameter conducts light.
Most likely they stripped off the buffer and bundled the 125u fibres.

To get an idea: The 62.5u cable has the same diameter as the Multimode GOF below but a larger light conducting area.
The just took a bundle of those 62.5u fibres to conduct the light. A bunch of fibres in parallel.

One can also use GRIN lenses (kind of an optical lens/concentrator that works both ways) where a larger diameter light source is made smaller and fits inside the 62.5 and then is expanded again to a larger diameter. A.K.A. as beam expanders. These are used in specific fiber optic connectors so a small spec of dirt won't wreck damping in a connector. Quite expensive because it has to be aligned.

 

[solderdude]

Gold plated metal connector ends affect something negativly?

Because Glass master has metal ends, POF has not. (only plastic)

I wish i can measure two of them but i don’t have any measurement device.

No, makes no difference. It is just a 1mm diameter plastic fiber similar to those in those lamps with all the fibers waving out.
Such a 'fiber' is just placed in a 'holder' that ensures it is in front of an LED and receiver. It does not matter if it is plastic, ceramic, metal or something else. 1mm diameter is easy to align.

 

[solderdude]

Shouldn't the opposite be true?

Optical connection solves the ground loop problem.

Yes, it will but is bandwidth limited. A high speed USB isolator is not limited. That isolator can have opto parts inside or small inductors.

 

[DonH56]

Aside: Do NOT look at the end of a network optical cable. Much higher power and can damage your eyes. TOSLINK is OK, just a red LED as @solderdude said.

 

[xaviescacs]

just a red LED

At some point, this "RED led" will allow for processors that don't dissipate heat.

The bottleneck is the receiver not the cable

In the telecommunications world it is known for decades that fiber can carry a lot more data than cooper. As many have said, the eventual issues with transferring digital audio over fiber are imputable to other equipment parts or to the data transfer protocol, as they can be bidirectional allowing for "sync", like ADAT or Ethernet, or not, like S/PDIF. Therefore, in my opinion, trying to solve that eventual issues by means a of a better cable makes no sense.

No physical transmission layer is perfect and this is why all data transfer implementations use bidirectional robust protocols. In fact, if all consumer audiophile electronics would adopt the pro protocols like ADAT, there will be much less room for snake oil marketing. Just try to find a hi-end optical cable in a pro store.

 

[solderdude]

The (mini)TOSLINK is merely a 1:1 'copy' of the electrical SPDIF signal.
An electrical H = (visible light, 660nm) LED on, An electrical L = LED off.
So protocol is exactly the same. Just 'optical' instead of electrical.
TOSLINK not biderectional.
It could be using optical splitters and/or using 2 colors and demux but SPDIF isn't bidirectional either.

What's needed is higher speed receivers but time-smear is lurking in 1mm fibers as well as damping limiting practical application.
MM, and let alone SM would require proper cleaning and handling. TOSLINK is more 'dummy proof' certainly for short distances and low bandwidths.