Why is there no Toslink 2.0?

[voodooless]

Jitter? Why does this still come up? The gear on either end sends then buffers before processing. There is no jitter in the end result. Dropout are the only possible downside of failed partial transmission. Again this is from my knowledge of fiber optic networks (I engineered multi-state cell backhaul) and ethernet. Maybe Toslink is different?

Jitter is not so much of an issue, synchronization and clock recovery is. In a distributed audio system, be it a studio, or a large stadium, you want all equipment running in the same clock domain, otherwise, you need resampling at all kinds of places to keep everything in sync. Couple that with low latency (so as little buffering as possible), and you have a few challenges at your hands.. and these solutions to those problems is what they're asking money for. Surely the hardware is ubiquitous networking hardware, and the protocol stack is just made to run on top of the ethernet phy. But creating a bit more lock-in is often good for business, especially if you can put some more stickers on your box because of it

 

[mansr]

Why does Dante even exist? It's just ethernet with their own transport/codec? Seems superfluous to the MANY existing codec's and transports we already have for ethernet (IP).

The only realistic alternative I'm aware of is AES67/Ravenna. Something tells me you'd be as dismissive of that.

 

[michaelahess]

So basically it comes down to the low real time latency that's expected.

I'd be curious if there are studies on this. Like in gaming, you sometimes have 100ms or more just in screen updates, the audio has to be quicker, but still in sync, so that's a challenge.

But then with the audio delay inherent in large venues, the screen delay might not even matter, 100ms delay on a big screen, still dwarfs the delay of the sound getting to the middle or back of the venue I'd assume. So in that regard, what's it matter?

Other than those directly in front of the speakers/monitors, and the performers themselves, all the delays will add up to a menajury of sound and light that is un-timable in the grand scheme.

 

[michaelahess]

The only realistic alternative I'm aware of is AES67/Ravenna. Something tells me you'd be as dismissive of that.

Not trying to be dismissive. Trying to understand if the tech is really necessary or just marketing BS. Ravenna seems to be open, so I would go with it over anything else as it's not trying to profit over existing technologies that are "free".

This sells me on them, until I would see a real world difference of course:

"You can create your own RAVENNA solution with no ongoing licensing fees"

Believe me, being in the industry I'm in, I seen my fair share of "magic" that costs many times more than the free or cheap alternatives, and returns gains so minimal as to be essentially inconsequential to the end product desired.

So how does all this play into Toslink though? I guess I took this way off topic, my apologies.

 

[mansr]

Not trying to be dismissive. Trying to understand if the tech is really necessary or just marketing BS.

_Something_ is necessary. You've repeatedly said just use Ethernet. Now Ethernet only takes packets and delivers them to the specified destination, maybe. To be useful, sender and receiver have to agree on the format and meaning of the data within those packets. That's what Dante and Ravenna both do. The feature set they offer is not, to my knowledge, available elsewhere. FTP isn't exactly suitable for real-time audio.

 

[michaelahess]

_Something_ is necessary. You've repeatedly said just use Ethernet. Now Ethernet only takes packets and delivers them to the specified destination, maybe. To be useful, sender and receiver have to agree on the format and meaning of the data within those packets. That's what Dante and Ravenna both do. The feature set they offer is not, to my knowledge, available elsewhere. FTP isn't exactly suitable for real-time audio.

Ethernet does nothing to validate delivery, it's just the highway. TCP/UDP are the normal protocols used to do this. TCP validates packet delivery and will retransmit if needed, however that's not a good fit for real time traffic. That's what UDP is for, however UDP won't retransmit, because for live traffic, who cares what happens after it happened? If there is a built in buffer of a reasonable size, TCP will deliver lossless performance, all else being equal. UDP needs only enough buffer to handle the processing delay on the receiving end. For live traffic this will be close to zero, but you CAN'T prevent packet loss with ANY protocol that doesn't allow for retransmits. Thus, what's going to do better than UDP, and why?

These technologies seem to be a customized low(er) latency version of UDP.

However, again having dealt with this tech for many decades, UDP on an uncongested network is flawless. So that's where I question the need.

And wanted to just get opinions on if it's really needed, or just "something" that isn't quantifiable.

 

[mansr]

Ethernet does nothing to validate delivery, it's just the highway. TCP/UDP are the normal protocols used to do this. TCP validates packet delivery and will retransmit if needed, however that's not a good fit for real time traffic. That's what UDP is for, however UDP won't retransmit, because for live traffic, who cares what happens after it happened? If there is a built in buffer of a reasonable size, TCP will deliver lossless performance, all else being equal. UDP needs only enough buffer to handle the processing delay on the receiving end. For live traffic this will be close to zero, but you CAN'T prevent packet loss with ANY protocol that doesn't allow for retransmits. Thus, what's going to do better than UDP, and why?

These technologies seem to be a customized low(er) latency version of UDP.

However, again having dealt with this tech for many decades, UDP on an uncongested network is flawless. So that's where I question the need.

And wanted to just get opinions on if it's really needed, or just "something" that isn't quantifiable.

UDP is still just blobs of unspecified data. Parameters like sample rate and number of channels need to be conveyed in a defined manner. Someone made a system that handles all the things professional audio needs and called it Dante. How would you have done it?

 

[goldenpiggy]

When doing a live show (as in a concert, not so much corporate talking head), priority is minimizing audio latency, NOT delaying audio to have perfect lip sync with the LED wall. Video coming in from cameras, going through wireless SDI transmitters, into a switcher, and finally onto the videowall processor will have much more latency than the audio, It would be ludicrous to even try to have the sound coming out of FOH (or worse, delay towers) delayed to be in sync with video. Just not done.

Stage noise is another reason why we minimize audio latency. Musicians absolutely hear (and feel) the FOH and whatever delay arises from those speakers, even if using IEMs (not uncommon to mix in some ambient noise on the IEM feeds.) It's why cardioid subs for really large shows and stage is important.

As far as lighting, even using traditional DMX, it's plenty fast since there's not much data compared to audio/video. So we don't really consider that latency in comparison to audio.

The generally industry acceptable audio latency is 8ms input to output when NOT using IEMs. Who came up with that, I have no idea. Personally I start hearing latency around 12msec. I've worked with guitarists that cannot stand 8ms. This becomes a problem when they insist on being on wireless AND using IEMs. There have been shows I've had to NOT use digital body packs (mind you pretty much all the current crop of wireless are digital), and go back to something like an analog Shure UR1/UR4D+ just to get rid of that last mile of latency for them. Of course nothing beats 1/4" from guitar into a DI box.

 

[voodooless]

Some info on the Dante Stack:

 

[michaelahess]

It's not blobs of unspecified data. Sample rate, number of channels, none of that matters to a digital transmission system, only to the device receiving the data, it's already IN the packet info encoded from the sending side's software. All ethernet based data is sent in frames, those frames know nothing of such trivialities.

UDP does not have sequence numbers like TCP, it dumps crap on the wire, assuming the sending end keeps it's packet generation in the correct order (for sample timing for example) then ethernet simply breaks those packets into frames and sends them along. The receiving end, with UDP, will not drop out of seq packets as it doesn't know they exist, but again, on uncongested networks, this doesn't happen.

EMI on a cat6 or other electrical faults can cause drops. The protocol running OVER UDP is what would keep track of packet sequence. There is nothing that protocol can do to "fix" latency or timing. Once it's on layer 1, ethernet does it's thing regardless. The only thing a protocol over UDP can do, is re-insert sequence numbers (or time stamps or whatever you want) to keep track of order, and drop out of order packets on the receiving ends protocol software. There is literally nothing else you can do. It's physics at that point. First come, first serve, now how do we process what we received?

 

[michaelahess]

Some info on the Dante Stack:

View attachment 122594

The only thing unique on that stack is the Audio Streaming in purple. The "num samples" and "audio format" are not at layer 1 or even 2, so the network itself has nothing to do with their magic. Only whatever that data is IN the packet and how it's processed on the listener's end.

I'm VERY familiar with PTPv1, think cell tower timing to GPS, this is nothing new, or special. CAT-TP is basically a connection oriented protocol that does what TCP already does. Bonjour is apple's crappy discovery protocol. Nothing here is magic, it's just the way it's deployed to devices. Think Lutron for smart home devices vs generic Zigbee or Z-Wave.

 

[michaelahess]

I'm not saying it doesn't do it's thing well, I'm saying, it's nothing others can't do for free if they understand how. Hence why there is an open standard to compete with it. But once you get the "works with" brigade started, it's hard to get out of that.

 

[goldenpiggy]

Well look at NDI...why has it taken off when RTSP, RTMP, WebRTC are free?
Auto-detect (for the most part), very low latency, and EVERYONE IS GETTING ON THE BANDWAGON.

 

[michaelahess]

EVERYONE IS GETTING ON THE BANDWAGON.

That is one hell of a motivator for sure!

 

[voodooless]

NDI is (royalty) free as well. Doesn't mean it's any good

 

[somebodyelse]

Nobody's saying there's anything special about Dante, AES67 or AVB - they're mostly using a collection of established standard protocols to do discovery and pass data over ethernet in a timely manner, and they're more similar than they are different. I get the impression Dante got a foothold because being proprietary meant Audinate could enforce interoperability, while AES67 had interoperability issues when manufacturers interpreted it a bit differently. AVB has the disadvantage of requiring more expensive network hardware because so far the stantard hardware timestamping and QoS capabilities it uses to guarantee latency and bandwidth are only implemented on a select set of AV targetted switches with high price tags, or enterprise level gear with very high price tags. Dante and AES67 don't have this guarantee, but work on the basis that with lesser but comodity QoS and a dedicated or lightly loaded network it's usually good enough, and you can use a parallel fallback network for a bit of belt-and-braces and still cost less than the AVB one. All are vastly overspecified as a successor to toslink though.

 

[mansr]

It's not blobs of unspecified data. Sample rate, number of channels, none of that matters to a digital transmission system, only to the device receiving the data, it's already IN the packet info encoded from the sending side's software. All ethernet based data is sent in frames, those frames know nothing of such trivialities.

The device sending the data and the device receiving it need to agree on the format. As you say, UDP doesn't care about that, so something else has to specify it. That something can be Dante. Do you also question why web browsers use HTTP and HTML and insist they should "just use TCP"? What you're saying about audio is just as daft.

 

[stevenswall]

Why does Dante even exist? It's just ethernet with their own transport/codec? Seems superfluous to the MANY existing codec's and transports we already have for ethernet (IP).

Is there another audio over IP signal that has hardware adapters so that I can get analogue or digital XLR out of any ethernet port, with ~11-16 channels that I can configure? Seems like the ultimate high end solution for mixed systems. (I want AES for my Genelec 8260 main speakers, XLR for my rear Kali IN-5 surrounds, and maybe RCA or some other connection for a couple of subwoofers.)

I'd love to see Dante and Ethernet as the standard. Or Wisa with adapters for actually good speakers. Or even Toslink 2.0 instead of eARC. They should also change the cable connector geometry, and you could plug in the cable in 4 directions and it would work, just like you can plug in MicroUSB and USB A cables in either right side up or upside down configurations with the right cable... Most companies are just ignorant or choose not to make things like that.

 

[michaelahess]

That would be hardware dependant.

You could literally use ftp to transfer all this data from point a to b with no difference from the Dante technology. The only difference is what the endpoints are doing with the actual data. It's all the same to ethernet and tcp/udp.

@mansr your comment is "daft" as even http (a protocol) can transfer the same data with the same integrity as Dante's protocol. How the end point deals with it matters, nothing else does.

If you are on a congested network, then the protocol could do more error correction, but again, can't change timing, only PTP at layer 2 can assist with timing frames. This also means QoS is useless as it's only going to go into affect on congested networks.

If you have a congested network, no amount of QoS, timing, etc will give you a perfect in sync data stream. It's by definition impossible.

 

[Sancus]

As far as I can tell, Dante is just a spec(that meets broadcast and studio requirements) for streaming audio over an Ethernet network. The hard part about any spec is not writing it or implementing it, but getting anyone to give a shit that you did and use your work.

Whether or not open or proprietary is the better model highly depends on the market and the company involved. They both have advantages, open specs tend to make lower cost products and lower barriers to entry, but proprietary ones tend to work better simply because the owner can enforce quality and interoperability standards.

Considering that the pro audio world cares a lot more about the cost of person-time than the cost of hardware, it's not surprising to me that a proprietary standard would win.