Coax v/s Optical (toslink)

[Lupin]

Plenty of dacs do 384 and 768 khz.

Which DACs do PCM 384 and PCM 768 over S/PDIF?
All modern DACs do PCM 384/786 over USB not sure I know any that do it over S/PDIF.

 

[Balle Clorin]

Depends on the sender and receiver, My receiver fails at 96k Toslink , but works fine at 48k, -Coax works at any rate

 

[Jimbob54]

Interesting, would you please share with us the results?
Thanks,

No longer use Roon but I'll see what I can do

 

[BitPerfect_]

Based on your experience, in digital audio, if a coax/optical cable will be not able to handle a specified sample rate let's say 192kHz, the sound will be interrupted OR will be still audible but the data will be down-sampled at the maximum sample rate supported by that cable?

It's true that once I've received an answer regarding the coax cables but meanwhile reading further, it looks like the things could be in other way.

 

[dualazmak]

Just for your reference, this page in Japanese, even written in 2013 ;
https://nw-electric.way-nifty.com/blog/2013/10/spdif-ff2e.html

would be a nice introduction to understanding technical aspects of S/PDIF and also AES/EBU.
Hope your web browser would properly translate the page into English.

I believe we can find many of the similar pages on S/PDIF and AES/EBU in English elsewhere, though...

 

[Jimbob54]

Based on your experience, in digital audio, if a coax/optical cable will be not able to handle a specified sample rate let's say 192kHz, the sound will be interrupted OR will be still audible but the data will be down-sampled at the maximum sample rate supported by that cable?

It's true that once I've received an answer regarding the coax cables but meanwhile reading further, it looks like the things could be in other way.

I've encountered devices that can't send and devices that can't receive. Never a cable that can't.

 

[Jimbob54]

Based on your experience, in digital audio, if a coax/optical cable will be not able to handle a specified sample rate let's say 192kHz, the sound will be interrupted OR will be still audible but the data will be down-sampled at the maximum sample rate supported by that cable?

It's true that once I've received an answer regarding the coax cables but meanwhile reading further, it looks like the things could be in other way.

OK. So this is Windows upsampling amazon HD to 192, sending via USB to my streamer which then has an optical (and coax) output. Optical to m500. Plays 192 fine. This was some old QED cable. I've had no problems with amazon basics and other cheapos.

 

[DonH56]

Based on your experience, in digital audio, if a coax/optical cable will be not able to handle a specified sample rate let's say 192kHz, the sound will be interrupted OR will be still audible but the data will be down-sampled at the maximum sample rate supported by that cable?

It's true that once I've received an answer regarding the coax cables but meanwhile reading further, it looks like the things could be in other way.

At best it simply will refuse to connect at the higher rate. At worst it connects with lots of errors leading to dropouts and popping noise. IIRC there is no hand-shaking so no means of down-sampling and I don't think I have seen any component automatically do that (there may be some receivers now that, upon getting too many errors, try a lower rate). Not like PCIe or SAS/SATA links (and I thnk ethernet though am not familiar with that protocol) that will negotiate and go through a training process so both ends find a "happy" data rate.

TOSLINK chips seem to have degraded in quality over the years; I think @restorer-john noted this? That many modern optical transceivers are an afterthought and exhibit very poor performance in terms of both bandwidth and transmission/reception capabilities.

I have not kept up with AES standards, but a while ago only coax supported higher rates and only for "regular" professional AES and not the S/PDIF variety used by most consumer products. There is no official I2S standard AFAIK but again not something I have followed. Years ago, developing a high-speed I2S interface, I discovered that unlike I2C there was no accepted industry I2S standard, though some companies were working on an ad-hoc standard for high-speed data converters that has since been implemented.

FWIWFM - Don

 

[dualazmak]

Just for your reference,,,

Although discontinued quite regretfully, Onkyo DAC-1000 (launched in 2010) is/was really amazing DAC featuring two S/PDIF Coaxial IN (max. 192 kHz), two S/PDIF optical IN (max. 96 kHz), one S/PDIF optical OUT (max 96 kHz), one AES/EBU digital IN (max 192 kHz), USB digital IN (max. 192 kHz), XLR balanced stereo analog OUT and RCA unbalanced stereo analog OUT; the sound quality is still really wonderful. I actually keep one DAC-1000(S), and it works perfectly fine up to 192 kHz 32 bit DAC processing;
https://www.jp.onkyo.com/audiovisual/audiocompornent/accessories/dac1000/index.htm
https://www.jp.onkyo.com/audiovisual/purecomponents/accessories/dac1000/spec.htm
https://www.amazon.com/Onkyo-DC-Converter-DAC-1000S-Japan/dp/B004FM92Z8

As I shared here, I fully confirmed the full sync connection by AES/EBU from OKTO DAC8PRO (Ch-1 and Ch-2) into Onkyo DAC-1000; when DAC-1000 is fed digital input through AES/EBU, the sync clock signal is given by upstream gears (DAC8PRO), and DAC-1000 does not use its own internal clock; in this way DAC8PRO and DAC-1000 are fully in sync. An ONKYO engineer also confirmed by email that "If DAC8PRO's AES/EBU digital out is fully compatible with the IEC90958 of AES3 Standard issued in 1985, then DAC-1000(S) would be automatically fully in sync with DAC8PRO, without using DAC-1000(S)'s internal clock."

 

[RPG]

Just for your reference,,,

Although discontinued quite regretfully, Onkyo DAC-1000 (launched in 2010) is/was really amazing DAC featuring two S/PDIF Coaxial IN (max. 192 kHz), two S/PDIF optical IN (max. 96 kHz), one S/PDIF optical OUT (max 96 kHz), one AES/EBU digital IN (max 192 kHz), USB digital IN (max. 192 kHz), XLR balanced stereo analog OUT and RCA unbalanced stereo analog OUT; the sound quality is still really wonderful. I actually keep one DAC-1000(S), and it works perfectly fine up to 192 kHz 32 bit DAC processing;
https://www.jp.onkyo.com/audiovisual/audiocompornent/accessories/dac1000/index.htm
https://www.jp.onkyo.com/audiovisual/purecomponents/accessories/dac1000/spec.htm
https://www.amazon.com/Onkyo-DC-Converter-DAC-1000S-Japan/dp/B004FM92Z8

View attachment 157063

As I sharted here, I fully confirmed the full sync connection by AES/EBU from OKTO DAC8PRO (Ch-1 and Ch-2) into Onkyo DAC-1000; when DAC-1000 is fed digital input through AES/EBU, the sync clock signal is given by upstream gears (DAC8PRO), and DAC-1000 does not use its own internal clock; in this way DAC8PRO and DAC-1000 are fully in sync. An ONKYO engineer also confirmed by email that "If DAC8PRO's AES/EBU digital out is fully compatible with the IEC90958 of AES3 Standard issued in 1985, then DAC-1000(S) would be automatically fully in sync with DAC8PRO, without using DAC-1000(S)'s internal clock."

"As I sharted here, I fully........" ;>) ;>)

Definitely one of most awesome typos I've seen in a long time!!!

 

[dualazmak]

Thank you, my shame.... I corrected the typo.

 

[mansr]

At best it simply will refuse to connect at the higher rate. At worst it connects with lots of errors leading to dropouts and popping noise.

The S/PDIF inputs on a Cambridge Audio receiver I had were specified as 96 kHz max. I connected a 192 kHz source anyway, just to see what happened. The receiver started smoking.

 

[mansr]

IIRC there is no hand-shaking so no means of down-sampling and I don't think I have seen any component automatically do that (there may be some receivers now that, upon getting too many errors, try a lower rate).

S/PDIF is strictly unidirectional. There is no way for the receiver to signal anything to the transmitter, so automatic rate negotiation is not possible. Some sources let you manually configure the maximum rate to output and will then resample anything exceeding that limit.

 

[terrys999]

I use pi 4 usb to my dacs Works perfectly.
I can also use optical out from cxn to adi 2 dac fs, at 192 works great.
Also if you feed cxn dsd , the cxn passes dsd64 from optical out to adi... as Dop not pcm. And yet Cambridge specify its highest at 96. Then again Cambridge do say 192khz with a good toslink cable.

 

[xaviescacs]

and I thnk ethernet though am not familiar with that protocol

Computer networks work with the so called OSI model or protocol stack. Ethernet corresponds to the Link layer. Every packet sent contains information about each layer, and each end device uses it in different ways. For instance, a router will typically only implement Link (ethernet) and Network (TCP/IP) layers. (there are routers that analyze application layers).

Almost each layer has a mechanism to protect against errors in their ambit, so to speak, although in detail it's a bit more complex.

In the case discussed here, namely, that an application receives an audio file with a higher bit rate than expected, I think there is no way for any layer in the protocol to detect this problem, because it isn't really a "network problem", and this should be dealt at application level, because this information its only found when examining the content being transferred itself. So the receiving application must "complain" about it and inform the sending application to act according to its needs. The negotiation then will not be done by the network protocols themselves but by the applications, so any error codes will be at application levels. For instance, UpNP works with HTTP, at application level, so I guess it will be using the standard HTTP error codes such as: 404 if the resource doesn't exist, 400 if the request can't be processed, and 406 if the content it's not acceptable.

 

[Vincent Kars]

that an application receives an audio file with a higher bit rate than expected, I think there is no way for any layer in the protocol to detect this problem

Very simple, this problem won't happen using the common network protocols.
UPnP is a popular one for streaming AV.
Indeed it is PnP (Plug and Play) because the devices discover each other over the network.
Just like in case of USB, they exchange their properties like "I can play 24/96 kHz PCM max", "I play FLAC", etc.
Hence the server knows the properties of the renderer and will down sample if needed. Likewise will convert if needed, etc.

 

[xaviescacs]

Very simple, this problem won't happen using the common network protocols.
UPnP is a popular one for streaming AV.
Indeed it is PnP (Plug and Play) because the devices discover each other over the network.
Just like in case of USB, they exchange their properties like "I can play 24/96 kHz PCM max", "I play FLAC", etc.
Hence the server knows the properties of the renderer and will down sample if needed. Likewise will convert if needed, etc.

Just for curiosity. The receivers keep sending this messages every t seconds or they respond when a possible sender asks for devices in the net?

 

[Vincent Kars]

To the best of my knowledge, on detecting each other, they exchange their properties.
Don't know their polling rate if this is what you are asking for

 

[Suffolkhifinut]

Thank you for the quick replies. I think I’ll try the coax first, and if there is a problem I’ll try the toslink.

Always liked toslink, one way it has an advantage of a coaxial connection is electrical isolation between the source and the DAC.

 

[xaviescacs]

To the best of my knowledge, on detecting each other, they exchange their properties.
Don't know their polling rate if this is what you are asking for

But to detect each other someone has to send the first message over the net. I was just curious to know if the end devices are telling they are there waiting for someone to connect to them, or when a streaming device gets connected to the net it sends a signal to let possible end devices to know about its presence and then they communicate their "properties" as a response to this request. Not very important, just curiosity.