We need a new standard in transferring digital signals between audio equipment.

[R1200CL]

AES/EBU SPDIF Toslink and USB. (I2S and probably more). I don’t include HMDI, but feel free to add that technology as well. 
 

Are these technologies outdated for modern digital audio ?

 

Shouldn't they at least be updated to be fiber optics ?

Wouldn’t we save us self al lot of issues regarding cables if all digital interfaces was via fiber optics ?

This includes clock signals. 

 

Which manufacturer is willing to start a new standard ? And why won’t they do ?

 

Can everything be converted to Ethernet ? Or at least use SFP as interface ?
 

I like to hear your thoughts about this, and hopefully some skilled members can participate. 
 

Do we need a new standard in transferring digital audio between our equipment ?

[sphinxsix]

 

Something for Bob Stuart, provided the new standard can be lossy (but offering deblurred sound of course)! 

 

[One and a half]

AES, SPDIF are missing clock signal data, well, the receivers screw up the clock data, so a new clock needs to consitute that data. AES can run for a 100m, SPDIF for 5m.

 

USB conducts noise from the source to host. SB is maxed at 2m without tricks.

 

HDMI has a shitty connector, can have clock data, but no one has set a standard.

 

Fibre can contain clock data, can run for thousands of metres, and pumps 10GB+/s. Seems ideal. 

 

Ethernet has Ravenna, that's taken off like a lead balloon, for consumer, pretty much a closed shop, Dante still has a commanding inroad to that market. Roon has better penetration for consumer devices, and wouldn't be around if uPNP was better supported by Marantz, Denon, Pioneer, Yamaha, Sony... see a a pattern?

 

So go with fibre. Now to agree on a protocol, interface, and acceptance from the computer industry, audio industry and the consumer when there are vested commercial interests everywhere pushing their own barrow and pro audio only wants to spend $20.

Take a look at the hi-res logo fiasco, two logos that mean the same thing or do they?

 

Good luck!

[yamamoto2002]

Fibre optic audio interfacing standard is already exists, it is called MADI. It is used at large venues like concert halls where there are many audio channels and cable length is very long

 

IMO another standard is not necessary but it will be invented anyway

 

From https://xkcd.com/927/

[yamamoto2002]

55 minutes ago, One and a half said:

AES, SPDIF are missing clock signal data, well, the receivers screw up the clock data, so a new clock needs to consitute that data.

 

With Biphase Mark Code (BMC), clock signal and pcm digital signal is encoded to one signal.

And on receiver, clock signal and pcm digital signal can be recovered by decoding BMC

 

[asdf1000]

1 hour ago, yamamoto2002 said:

Fibre optic audio interfacing standard is already exists, it is called MADI. It is used at large venues like concert halls where there are many audio channels and cable length is very long

 

Anything more than PCM192kHz?

 

With 192k, up to how many channels?

 

Even Denon AVRs (mainstream) support DSD128 these days.. can MADI support DSD128?

 

Ravenna supports PCM384kHz and DSD256 right now (can do 8 channels at these rates easily) so that should be front runner !

 

[PeterSt]

9 hours ago, R1200CL said:

Shouldn't they at least be updated to be fiber optics ?

 

This is irrelevant because it is just a vehicle. Not a protocol or something. And as has been said, it is used for as long as the CD is around. Additionally you'll always need to deal with conversion because no DAC or PC will be all the way glass internally.

 

9 hours ago, R1200CL said:

Can everything be converted to Ethernet ?

 

This is a bit of the same response. It would be a matter of setting the standard, but without it you can already chose it ans use it.

 

2 hours ago, One and a half said:

HDMI has a shitty connector, can have clock data, but no one has set a standard.

 

There must be something wrong here because the connector is as shitty as how you buy the cable (the one we use is far from shitty but also costs 10 euros or so). The generic cables you can buy are 100% shitty because no electrical standards are  applied (this mostly relates to grounding and the shell). 

Lastly, HDMI is used for i2s only and although indeed nobody set a standard, every DAC etc. manufacturer uses the same pinout, and so do I at providing our HDMI^2. It always works for everyone.

This is not to be confused with HDMI from your monitor that carries video and sound at the same time. That "standard" is not for audio at all. It is easy to think it is though. So only i2s ... (just as often done by Ethernet cable as well).

[R1200CL]

4 minutes ago, PeterSt said:

This is irrelevant because it is just a vehicle. Not a protocol or something.

So you could easily create fiber in on your DAC ?

Both USB and SPDIF?

 

Yes, I understand it’s meaningless unless the sender also supports same interfaces. 
So would it be worth making converters ?

[asdf1000]

3 hours ago, One and a half said:

Ethernet has Ravenna, that's taken off like a lead balloon, for consumer, pretty much a closed shop, Dante still has a commanding inroad to that market.

 

There's also AVB, as used by RME and some others.

 

[PeterSt]

1 hour ago, R1200CL said:

So you could easily create fiber in on your DAC ?

Both USB and SPDIF?

 

But of course ! This is already because there are many after market products for this. I mentioned Adnaco elsewhere recently (they were the first with this IIRC, more than 10 years ago). It will give you an idea.

But it won't sound better because of it. There wil be isolation, but what this does is "relative". All together it is more harmful than useful.

 

Etc. etc. etc.

(can of worms stuff)

 

[lmitche]

1 hour ago, PeterSt said:

 

But of course ! This is already because there are many after market products for this. I mentioned Adnaco elsewhere recently (they were the first with this IIRC, more than 10 years ago). It will give you an idea.

But it won't sound better because of it. There wil be isolation, but what this does is "relative". All together it is more harmful than useful.

 

Etc. etc. etc.

(can of worms stuff)

 

Hi Peter,

 

Have you listened to the Adnaco USB solution with industrial 10gbps SFPs, high quality fiber and high quality power supplies?

 

Done properly, SQ beats anything else heard here.

 

Larry

 

[PeterSt]

4 hours ago, lmitche said:

Have you listened to the Adnaco USB solution with industrial 10gbps SFPs, high quality fiber and high quality power supplies?

 

Thank you Larry. But no, I did not do that (back at the time !). I know that the expected culprit was the power supply, but back then there was no time to make one (the fine power supplies were far more rare back then), because the unit had to be send back to Canada (I think that was Canada).

If today this works, then good ! But the reason would be beyond me, with the isolators we currently have, and which also did not exist back then for the highest speed of USB2 (480).

But sure I believe you. The why could be interesting ...

[davide256]

17 hours ago, R1200CL said:

AES/EBU SPDIF Toslink and USB. (I2S and probably more). I don’t include HMDI, but feel free to add that technology as well. 
 

Are these technologies outdated for modern digital audio ?

 

Shouldn't they at least be updated to be fiber optics ?

Wouldn’t we save us self al lot of issues regarding cables if all digital interfaces was via fiber optics ?

This includes clock signals. 

 

Which manufacturer is willing to start a new standard ? And why won’t they do ?

 

Can everything be converted to Ethernet ? Or at least use SFP as interface ?
 

I like to hear your thoughts about this, and hopefully some skilled members can participate. 
 

Do we need a new standard in transferring digital audio between our equipment ?

It sucks that we don't have an optical ethernet DAC standard implemented supporting rates up to 512 DSD.  Being able to stream audio over optical ethernet out

direct to  any DAC would be my best of all possible worlds... but not if that requires streamer integrated with the DAC because streamer software obsolesces

[R1200CL]

@davide256

How can this be possible without streaming SW ?

What’s the alternative ? 

[R1200CL]

It seems to me that if a manufacturer is willing to build optical USB into their products, we could have something good coming. 
 

But are we sure various optical USB will work together ?

(Assume we use SFP or SFP+)

[davide256]

5 hours ago, R1200CL said:

@davide256

How can this be possible without streaming SW ?

What’s the alternative ? 

You don't need streaming software to feed a DAC data. You just need a layer above Ethernet that preserves and enhances the data handling logic

provided in the local connection protocols of Toslink and coax. Since you could be streaming between a server in Australia and a DAC in the US,

this would likely be a standardized device driver functioning at the IP level (network DAC) in a streamer sending data out its wired or fiber Ethernet port,

also would likely require pairing like Bluetooth does  to verify endpoint DAC is compatible Both ends would have to have bigger window support for latency

delays similar to VoIP needs. USB 's LRC issues would be eliminated

[R1200CL]

11 minutes ago, davide256 said:

You don't need streaming software to feed a DAC data.

But even your solution need something equal to streaming SW in order to work ? 
Isn't this where Sonore endpoints is good examples of products that already does this ?

You’re talking about developing a new protocol by using Ethernet ? Like RAAT maybe ?

[davide256]

45 minutes ago, R1200CL said:

But even your solution need something equal to streaming SW in order to work ? 
Isn't this where Sonore endpoints is good examples of products that already does this ?

You’re talking about developing a new protocol by using Ethernet ? Like RAAT maybe ?

Streaming SW = multi volume encyclopedia of functionality

RAAT, UPNP = network transport, 1 volume of Streaming SW functionality, not hardware specific

 

I don't want to see IP application complexity /overhead dragging down a virtual point to point connection, making DAC designers step outside their black box. For the DAC designer this should be a firmware chip managing an Ethernet port that behaves to them with data flow logic similar to Toslink/coax/USB and where the distant end uses a device driver designed for WAN connection handshake and data flow to their DAC Ethernet chip.

 

Think of a  network printer... you can print anywhere if the IP address is accessible and you have installed the device driver for the printer.

[fas42]

No. As I've recently found, boring ol' Toslink is fine - a bottom of the barrel DVD player, fed via an el cheapo, "came with the box" cable, into a decent active speaker does a fine job. Upgrading the quality of any of the areas of the relevant circuitry, and the parts used, can only improve that - optical eliminates many electrical issues, the things which USB is severely affected by, it seems.

 

The quality of the sending device is important - friend up the road uses two cheap DVD players in the same manner; and it was clear that the player used made a difference - optical can't eliminate every factor.

[MetalNuts]

21 hours ago, One and a half said:

AES, SPDIF are missing clock signal data, well, the receivers screw up the clock data, so a new clock needs to consitute that data. AES can run for a 100m, SPDIF for 5m

 

Do u mean AES, SPDIF cannot carry clock data together with the music data?

[R1200CL]

5 hours ago, davide256 said:

You don't need streaming software to feed a DAC data. You just need a layer above Ethernet that preserves and enhances the data handling logic

provided in the local connection protocols of Toslink and coax. Since you could be streaming between a server in Australia and a DAC in the US,

this would likely be a standardized device driver functioning at the IP level (network DAC) in a streamer sending data out its wired or fiber Ethernet port,

also would likely require pairing like Bluetooth does  to verify endpoint DAC is compatible Both ends would have to have bigger window support for latency

delays similar to VoIP needs. USB 's LRC issues would be eliminated

This will require HW changes to DAC’s. I would assume any DAC manufacturer that consider SFP or RJ45 interface will follow the Ethernet standard. 
 

I’m more thinking small manufacturer adding fiber interfaces for existing protocols, either USB, AES/EBU or SPDIF. Then in your present DAC, will need a small converter box from fiber to the suitable input. 
 

So I think developing a new protocol or standard is highly unlikely, but changing the transfer media from copper/coax to fiber should be more doable. 
 

I’m not sure if SFP is needed. Wouldn’t toslink type be sufficient ? Save space. Keep it simple. 

[One and a half]

59 minutes ago, MetalNuts said:

 

Do u mean AES, SPDIF cannot carry clock data together with the music data?

My original post was badly worded. Too late to edit.

 

Wikipedia explains better:

 

Limitations
The receiver does not control the data rate, so it must avoid bit slip by synchronizing its reception with the source clock. Many S/PDIF implementations cannot fully decouple the final signal from influence of the source or the interconnect. Specifically the process of clock recovery used to synchronize reception may produce jitter.[9][10][11] If the DAC does not have a stable clock reference then noise will be introduced into the resulting analog signal. However, receivers can implement various strategies that limit this influence.[11][12]

 

Many if not all S/PDIF receivers cannot recover clock data at all due to the difficulties in introducing jitter. To overcome this issue in the pro audio world which uses AES3, external clocking overcomes that problem, or as implemented in the Mutec MC [also RME..possibly] models where a local clock with lowish jitter can re-introduce the clock.

 

Ideally the clock data from the source should be continue through the interface, then again the source clock should have high precision, and that equals high cost.

 

Maybe we are looking at this all wrong from a digital perspective reaching a brick wall and invent some analog system that doesn't introduce clicks and pops, or fades over time, wears out heads. Wasn't Microsoft working on some biological approach?

[MetalNuts]

31 minutes ago, One and a half said:

My original post was badly worded. Too late to edit.

 

Wikipedia explains better:

 

Limitations
The receiver does not control the data rate, so it must avoid bit slip by synchronizing its reception with the source clock. Many S/PDIF implementations cannot fully decouple the final signal from influence of the source or the interconnect. Specifically the process of clock recovery used to synchronize reception may produce jitter.[9][10][11] If the DAC does not have a stable clock reference then noise will be introduced into the resulting analog signal. However, receivers can implement various strategies that limit this influence.[11][12]

 

Many if not all S/PDIF receivers cannot recover clock data at all due to the difficulties in introducing jitter. To overcome this issue in the pro audio world which uses AES3, external clocking overcomes that problem, or as implemented in the Mutec MC [also RME..possibly] models where a local clock with lowish jitter can re-introduce the clock.

 

Ideally the clock data from the source should be continue through the interface, then again the source clock should have high precision, and that equals high cost.

 

Maybe we are looking at this all wrong from a digital perspective reaching a brick wall and invent some analog system that doesn't introduce clicks and pops, or fades over time, wears out heads. Wasn't Microsoft working on some biological approach?

 

Thanks for the clarification. 

[One and a half]

22 hours ago, PeterSt said:

There must be something wrong here because the connector is as shitty as how you buy the cable (the one we use is far from shitty but also costs 10 euros or so). The generic cables you can buy are 100% shitty because no electrical standards are  applied (this mostly relates to grounding and the shell). 

Lastly, HDMI is used for i2s only and although indeed nobody set a standard, every DAC etc. manufacturer uses the same pinout, and so do I at providing our HDMI^2. It always works for everyone.

This is not to be confused with HDMI from your monitor that carries video and sound at the same time. That "standard" is not for audio at all. It is easy to think it is though. So only i2s ... (just as often done by Ethernet cable as well).

Isn't I2S limited only by a few cm? Or is that something that Gordon Rankin said. I2S over LVDS is certainly possible if there's a length of wire on it, or has I2S morphed into an LVDS transmission these last few years?

[PeterSt]

18 minutes ago, One and a half said:

or has I2S morphed into an LVDS transmission these last few years?

 

It has. And it comes over HDMI as well. However:

 

19 minutes ago, One and a half said:

Isn't I2S limited only by a few cm?

 

It formally is. But if one is a bit more experienced on i2s, (like designing D/A converters which I do) then you are quite well capable of making a cable for it which even works very well at 200cm. Well, this is exaggerated, but the other day I really sold an HDMI^2 of that length and never saw it back.

Notice that i2s contains the raw clock (oscillator) signal on one of its wires, so you really need to be careful and know what you're doing, including the ability to measure at the speeds of concern (say 45MHz).

 

Point is: for quite a long time by now (over 10 years, I'd say) DACs with external i2s connections/inputs are offered and because Ethernet cable as well as HDMI cable offer the proper grounding and twisting in the internal cable, the i2s data actually transmits quite well inherently already. Still, although I recall my first i2s connection from the PC and a tweaked Juli@t card to be 45 cm of length, that was a. way better than the Jul@t itself via its digital outputs, but b. exhibited way too much jitter.

So notice that the length of the i2s cable induces more jitter at the longer length. But not it you take care of the signal strength, to name something. In the case of the separately sold cable it is really a matter of taking all precautions about the signal remaning "as strong", the easiest explained by means of the cable having the least roll off at the longest length. That this implies proper shielding, proper impedance margins and from there the right dielectric, is something which makes that not everybody can do this "just like that".

 

LVDS is indeed about the signal strength, but mainly about the signals being offered in balanced fashion (say like XLR does). DACs accepting LVDS will work with HDMI (or maybe something proprietary but I have never seen that).

Btw, LVDS is also an internal "wire" (chip-to-chip) thing, but it is better than normal i2s.