Audiophile Ethernet exists: the AVB/TSN thread

[somebodyelse]

Funny you mention this. We recently decommissioned some switches and looked randomly at their logs on the syslog server ... Not one dropped packet, in a quarter (3 months) on several dozen of GbE interfaces. Not one... Said interfaces had multimedia on them ...
Seriously would like to know what this AVB brings that standard Ethernet doesn't ...
A "solution" in search of a problem?

Peace.

I guess it depends on what you mean by 'standard Ethernet' - it's using things standardised under 803.1 and 803.3 just like the switches you deal with. If you're dealing with enterprise level switches there's a good chance they implement most or all of the necessary extensions, but most cheaper switches don't. I suspect this has more to do with market segmentation and that most users needing to deal with precision time also have deep pockets, and less to do with the actual cost of implementation. Think telecoms companies, high frequency traders and big industrial sites. The switches from the likes of MOTU use relatively cheap silicon that may be in something much cheaper that doesn't advertise the capability.

The 'problem' is being able to guarantee bandwidth and low latency between source and endpoint, not just have it be good enough almost all of the time. It turns out it's not only a problem in certain (mostly large) AV situations. Real-time industrial control applications have a similar problem, hence the change of name from AVB to TSN (Time Sensitive Networking). If "good enough almost all of the time" is sufficient you can use Dante, AES67 etc. with commodity network switches. That probably applies to most professional situations, let alone hifi applications. Most of those protocols are using most of the same standards underneath anyway, just with slight differences in how they use them.

 

[somebodyelse]

I could see wanting something of the sort for gaming, VOIP or conferencing, but for simple media streaming, I'd think that buffering would suffice..?

My consumer-grade modem/router has settings for media prioritization, but in practice, I saw no real benefits, maybe because traffic on my network is pretty low to begin with.

AVB really isn't meant for any of those things, and couldn't be used for most of them anyway. Professional e-sports might have a case for something similar when played on a closed network. For domestic use I can't think of a situation where AVB would be necessary. There might be a few situations where it could be justified as MOTU's entry level AVB gear gives a lot of bang for the buck even before you consider the AVB capability.

 

[dc655321]

And, last but not least, all Ethernet interfaces are not created equal. I have been testing Gigabit Ethernet adapters and I found out that the typical Realtek USB-C to GbE can´t sustain 1 Gbps in full duplex, consuming an insane amount of CPU in the process.

How have you teased apart hardware from software (NIC driver) issues?

 

[FrantzM]

The problem is, what happens if you have a busy network combining many workloads? You need the network to prioritise audio traffic properly.

In a big system with many channels and distribution over Ethernet you need clock synchronization.

And, last but not least, all Ethernet interfaces are not created equal. I have been testing Gigabit Ethernet adapters and I found out that the typical Realtek USB-C to GbE can´t sustain 1 Gbps in full duplex, consuming an insane amount of CPU in the process.

The mechanisms to prioritize trafic are well known, understood and applied. As in anything, there are bad implementations, and you may find the odd GbE interface that can't sustain serious trafic... and there are, of course those that can and do it reliably. These are not terribly expensive either. We are at the point where 40 Gbit/s interfaces are commonplace, assuming the worst of these, would work at 25% of the rated throughput... you are left with 10 Gbit/s... I also fail to see the need for full duplex audio at 1 Gb/s , I could be wrong.
Nowadays it is commonplace for an enterprise network to carry enterprise data. voice, video, security (video and ACS) and Paging data, with no issue. This is most of the time transparent to the users. The IT people see to that and most of us (IT people), utilize for that, vanilla Ethernet...
I fail to see the need for a special flavor of Ethernet. I stand to be educated...

Peace

 

[delta76]

I don't understand - ethernet works fine already for audio streaming and networking applications, doesn't it? dropped packets are resent, and the timing accuracy of the ethernet connection is irrelevant to the timing accuracy of audio playback.

Exactly.
Tap audiophile in to any device name, and charge double and triple for it.

 

[MaxwellsEq]

I've been involved in several generations of national and international serial and packet (Ethernet / IP) media networks, including debugging complex faults. There is nothing in domestic A/V which challenges a good quality domestic router. People who suffer dropouts have a hardware or setup issue, not a need for some broadcaster-based protocol or one used for HV distribution control or trading floors.

 

[TonyJZX]

yeah this is something anyone who's in this industry would be rolling their eyes at

there is no problem to solve with hardware that's even a decade old or more

as people surmise, invested groups see an opportunity to make money and so they are inventing a solution to a non existent problem

but if you need to pay money to check a box (ie. what we call a "tick and flick" regulation) then this is it

as people have alluded to... systems used on trading floors are MUCH more time critical than the OP's topic and they've been in operation on current protocols for quite a while now...

 

[mppix]

I agree, TSN does not really solve 2 channel audiophile problems (what are actual audiophile problems?).
My point is more that one can install a studio-grade low-latency TSN network for (much) less than the cost of an audiophile Ethernet cable

Note that (layer 3) AES67 does similar things and it can leverage (layer 2) TSN clock synchronization and stream reservation. You are welcome to generalize the thread to include AES67.

Interestingly, TSN solves some of my audio problems but I may also not know how to solve them differently.

1. My cable clutter is virtual, e.g. (not my system)
   
   
2. I try to avoid proprietary networking solutions with a potential for vendor lock-in and planned obsolescence, e.g. Sonos.
   On the other hand, TSN supports a high number of uncompressed high-res audio streams.
   I use this for example to re-map my work/living room depending on usecase. The room layout need a sonic inversion and TSN makes it simple to remap front/surround speakers.
3. It becomes simple to deploy (powered) multichannel systems: just plug each speaker into the switch and assign the stream.
   Some pro speakers, e.g. Neuman, support AES67 (variations) for this. This avoids the interface (digital -> analog) and speaker (analog -> digital) conversion steps.
4. Bonus: Apple messed up the timing of USB interfaces on the M1/M2 chips (kind of, next gen OS seems to solve it). No problem with TSN.

I am sure the above can be done differently as well. An upcoming one may be harder to achieve today: WirelessTSN is starting to take shape. This would support (professional) wireless multichannel/Atmos systems with (low) latency guarantees, e.g. screen synchronization.

 

[mppix]

Guarantees over wireless? Then the guarantee is it will fail in 1 in so many times?

5G too

Wireless TSN – Definitions, Use Cases & Standards Roadmap White Paper | Avnu Alliance

Avnu Alliance: Wireless TSN – Definitions, Use Cases & Standards Roadmap White Paper Recent advances in 5G and IEEE 802.11 wireless connectivity technologies in providing low latency and high reliability have generated significant interest in extending TSN capabilities over wireless. Wireless...

avnu.org

 

[mppix]

Funny you mention this. We recently decommissioned some switches and looked randomly at their logs on the syslog server ... Not one dropped packet, in a quarter (3 months) on several dozen of GbE interfaces. Not one... Said interfaces had multimedia on them ...
Seriously would like to know what this AVB brings that standard Ethernet doesn't ...
A "solution" in search of a problem?

Peace.

The mechanisms to prioritize trafic are well known, understood and applied. As in anything, there are bad implementations, and you may find the odd GbE interface that can't sustain serious trafic... and there are, of course those that can and do it reliably. These are not terribly expensive either. We are at the point where 40 Gbit/s interfaces are commonplace, assuming the worst of these, would work at 25% of the rated throughput... you are left with 10 Gbit/s... I also fail to see the need for full duplex audio at 1 Gb/s , I could be wrong.
Nowadays it is commonplace for an enterprise network to carry enterprise data. voice, video, security (video and ACS) and Paging data, with no issue. This is most of the time transparent to the users. The IT people see to that and most of us (IT people), utilize for that, vanilla Ethernet...
I fail to see the need for a special flavor of Ethernet. I stand to be educated...

Peace

TSN is to Ethernet what PREEMPT_RT is to the Linux kernel: it introduces real-time capabilities to a system designed for throughput. It mainy introduces synchronization and stream reservation. Also TSN is standardized so it will work with faster bitrates than 1Gbit/s as well.

A big driver behind TSN are safety critical real-time systems. However, TSN remains excellent at audio-video. I don't think you'd use it to pull a stream form the internet but, for example, to stream digital audio to the speakers and maintaining them in sync - just my thoughts.

Of course, the point of standardizing/promoting TSN is to make Ethernet capable of routing the sound from stage to mixers to speakers of a Rhianna concert (or your favorite artist that plays in a large-scale venue for a 100,000 people), synchronize lights, etc. I just like that we can do something very similar at home for $500.

Edit/addition: With TSN, it would be trivial to link two 8channel interfaces for an ATMOS setup

 

[Chrispy]

Basically another LOL thread?

 

[MaxwellsEq]

I agree, TSN does not really solve 2 channel audiophile problems (what are actual audiophile problems?).
My point is more that one can install a studio-grade low-latency TSN network for (much) less than the cost of an audiophile Ethernet cable

Note that (layer 3) AES67 does similar things and it can leverage (layer 2) TSN clock synchronization and stream reservation. You are welcome to generalize the thread to include AES67.

Interestingly, TSN solves some of my audio problems but I may also not know how to solve them differently.

1. My cable clutter is virtual, e.g. (not my system)
   View attachment 302742
2. I try to avoid proprietary networking solutions with a potential for vendor lock-in and planned obsolescence, e.g. Sonos.
   On the other hand, TSN supports a high number of uncompressed high-res audio streams.
   I use this for example to re-map my work/living room depending on usecase. The room layout need a sonic inversion and TSN makes it simple to remap front/surround speakers.
3. It becomes simple to deploy (powered) multichannel systems: just plug each speaker into the switch and assign the stream.
   Some pro speakers, e.g. Neuman, support AES67 (variations) for this. This avoids the interface (digital -> analog) and speaker (analog -> digital) conversion steps.
4. Bonus: Apple messed up the timing of USB interfaces on the M1/M2 chips (kind of, next gen OS seems to solve it). No problem with TSN.

I am sure the above can be done differently as well. An upcoming one may be harder to achieve today: WirelessTSN is starting to take shape. This would support (professional) wireless multichannel/Atmos systems with (low) latency guarantees, e.g. screen synchronization.

The big three or four router/switch vendors have been trying to introduce higher-level distributed and virtual control planes (acting over the top of generic layer2 inter-bridge and layer3 inter-routing protocols and exploiting open standard or proprietary QoS) since the late 1980s. I must have been to hundreds of vendor demonstrations of this. If it could be made to work, it would be bliss. But to date, it merely ties you into a vendor's implementation. Perhaps AVB / TSN will be the one.

In practice, what has worked to date is well implemented and managed routing and bridging architectures and multiple higher layer control planes for the services above. Even the simplest office network these days handles thousands of real-time video calls and conference effortlessly.

But as I said before, any properly set up, high quality domestic gigabit bridge/router is totally capable of handling any domestic A/V demand without adding guaranteed traffic queues.

 

[mppix]

The big three or four router/switch vendors have been trying to introduce higher-level distributed and virtual control planes (acting over the top of generic layer2 inter-bridge and layer3 inter-routing protocols and exploiting open standard or proprietary QoS) since the late 1980s. I must have been to hundreds of vendor demonstrations of this. If it could be made to work, it would be bliss. But to date, it merely ties you into a vendor's implementation. Perhaps AVB / TSN will be the one.

In practice, what has worked to date is well implemented and managed routing and bridging architectures and multiple higher layer control planes for the services above. Even the simplest office network these days handles thousands of real-time video calls and conference effortlessly.

But as I said before, any properly set up, high quality domestic gigabit bridge/router is totally capable of handling any domestic A/V demand without adding guaranteed traffic queues.

Technically TSN is the level 2 standard.
Any switch with VLAN (and PTP) supports it.

TSN is not intended to replace non realtime networking. It is intended to enable new usecases.

 

[MaxwellsEq]

Technically TSN is the level 2 standard.
Any switch with VLAN (and PTP) supports it.

TSN is not intended to replace non realtime networking. It is intended to enable new usecases.

I'm aware of this. These use case are irrelevant in a domestic setting.

 

[mppix]

I'm aware of this. These use case are irrelevant in a domestic setting.

Why?
I wouln'd mind skipping the DAC stage altogether and just stream audio to (active or diy) speakers over the network.

 

[tmtomh]

Why?
I wouln'd mind skipping the DAC stage altogether and just stream audio to (active or diy) speakers over the network.

If you stream audio to speakers over your network, you're still going through a DAC - just the DAC in the speakers. The only difference is that the speakers would have to have an ethernet or wi-fi input in addition to a USB or AES (or optical or coax) input. The ethernet protocol doesn't need to be changed for that to happen.

 

[kevin1969]

AVB is not meant for "audiophile" applications. It's intended for live sound, studio, and broadcast applications with requirements for low-latency and reliable real-time transmission, where general-purpose TCP/IP networks may be inadequate. It's an open standard, but requires software support and specialized networking hardware.

For music consumption, there are no evident advantages over standard TCP/IP networks.

Exactly. People don't understand that they're not really streaming anything, they're just downloading a file from a server. TCP takes care of everything.

 

[mppix]

If you stream audio to speakers over your network, you're still going through a DAC - just the DAC in the speakers. The only difference is that the speakers would have to have an ethernet or wi-fi input in addition to a USB or AES (or optical or coax) input. The ethernet protocol doesn't need to be changed for that to happen.

Not necessarily for class-D amps. DSPs can accept digital inputs and command directly the power stage.

 

[NTK]

Not necessarily for class-D amps. DSPs can accept digital inputs and command directly the power stage.

Bruno Putzeys explained why this is a not such a great idea. If you are thinking of simple LP filtering the "digital" PWM pulses to generate the analog waveform, any imperfections in the pulses will manifest at the output as distortions after filtering. This is much much harder for the high voltage high current outputs needed to drive difficult loads such as loudspeakers, as opposed to the normal DAC that only need to drive an op-amp.

The Truth About Digital (Class D) Amplifiers

Firstly I'd like to point out that "digital amps" is a misnomer. There are two categories: Analog-controlled class D. Switching amplifiers…

www.audioholics.com

Quote:

One should ask the question: would any D/A converter designer in his right mind build a DAC using power components? Probably not. Then how about the old argument that digital-to-the-end is best? Well, I should think the D/A barrier is best put precisely where it allows the whole signal chain to perform at its best and why should we believe that this is necessarily right at the end? Quite obviously the concept of a digital class D amplifier was dreamt up by DSP folks who presumed that the signal should be kept out of the big bad analog world as long as possible, at the same time expecting the power stage, power supply and filter (all highly analog in nature) to perform flawlessly.​

 

[tmtomh]

Not necessarily for class-D amps. DSPs can accept digital inputs and command directly the power stage.

Still doesn't require a new ethernet protocol.