Hello, thanks for the answer.

Is there a sample setup for the whole AVB network thing for studios? Recommended/working network cards/router/software for PC?

I have done some research and compared to Dante it is all pretty vague still.
Are there any plans on releasing more AVB network I/Os, premaps, etc?

Wanted to share a little list of potential cards and more... for PC users:

AVB for PC:

https://1drv.ms/w/s!AsdhRYxqnBY1hYB88HYm_VkbC--shQ

To run the device do we need the AVDECC Controller software or is there something included?

MACs should be able to directly connect to AVB networks?

What about laptop PCs? Any recommended laptops?

Would be awesome to collect a list or some sort of database. Would make my decision much easier.

Also the network setup for AVB. Any articles or guides on that? How to combine it with internet/wlan/lan etc

Thanks

Thanks

Really love RME, but the whole AVB thing seems to be kinda uncharted territory especially for PC users.

I agree that it must appear quite vague and blurry to newcomers.

As Ramses says, it shouldn't require a specific sample setup. While it is not necessary to understand all the AVB specifics, you should understand one thing about AVB, which is the concept of streams. Streams are like virtual cables across your AVB network, and are shielded from other traffic and deterministic (they have a fixed latency).

This is different from legacy ethernet or 'Layer 3' network technologies. In terms of interoperability, you usually only need to check the supported stream size on both ends, but in future you don't even have to check that, because the subset of AVB marketed as 'MILAN' makes a certain stream size mandatory for manufacturers. Two MILAN products can always connect, two AVB products only if they support the same stream size. See also this video: https://www.youtube.com/watch?v=FodSNTc2zrM

While RME is not a member of the MILAN group at this time, it is obvious that MILAN is the only possibility to achieve guaranteed plug'n'play interoperability, which is what customers need. So the current firmwares of Digiface AVB and M-32 Pro series already play nicely with MILAN products.

That is maybe due to Dante being a network solution that has always been marketing-driven (give customers a solution that solves their problems now), while AVB is by itself only an open set of standards and the people implementing it are technology-driven (give customers a great solution once the standards are tackled and the implementations mature). By allowing common switches, Dante could solve many issues much faster. And they did this very well!

AVB builds on an enhancement of Ethernet, which requires the IT industry (which is in comparison to the audio industry a HUGE industry) to implement these standards first (small switch manufacturers follow the implementations of huge switch manufacturers such as Cisco, and that takes time). It looked like it would never happen a couple of years ago, that may be one of the reasons Audinate/Dante 'pulled the plug' on their AVB implementation (they wanted to use the advantages of deterministic ethernet in the beginning, see: https://www.lectrosonics.com/Support/ph … v1%202.pdf).

While that was bad 'marketing' for AVB, it actually did not mean that the underlying technology wasn't superior or would be obsolete. In fact, also the much newer AES-67 standard mentions AVB as an enhanced ethernet technology that can be used to improve performance in other types of networks. I personally assume that deterministic ethernet will become much more common in consumer switches, many devices already have the required chips inside and simply didn't activate them (I'm looking at you, Linksys WRT3200ACM!).

Of course more AVB products are planned. The motivation behind it is simple:
a) it's an open standard that manufacturers can fully understand and develop with - they can use existing implementations or develop their own (as RME did)
b) it solves the remote control issues that MADI has (AVDECC can be used to control any parameter, for example of an M-32 DA pro, including output gain, clock, preset switching, even metering options, and yes, you can even turn on dark mode if the AVDECC controller has implemented the corresponding control). So there is no need to implement our own remote control, which is the case with most other network audio technologies.
c) it solves the cable issues that MADI has (optical and coaxial cables are not the best option for live recordings...). Also, more audio channels at higher sample rates per cable, see http://abc.statusbar.com
d) routing!
e) no dedicated network is required, even in complex setups. Users who use new features like cloud collaboration on their DAW should not need to run a separate network just for internet.

The Digiface AVB has an AVDECC Controller as part of the driver to connect streams and set the clock, but you can also use the other controllers available, such as HIVE (search Google for HIVE AVB Controller).

Yes, they can, if they use the Thunderbolt 2-1GigE adapter with Broadcom chip (USB adapters do not work). The current developer Beta of Mac OS 10.15 has even implemented the MILAN stream format (AAF), which I haven't tested yet.
I have not done recordings with the built-in AVB capabilities of my Mac though, and there have been reports that it doesn't work well in combination with certain AVB implementations or certain Mac models. A Digiface AVB with its USB 3 Core Audio drivers is a much better solution for anyone relying on their AVB connection for professional recordings - the built-in capabilities can be tested and used for non-critical applications, such as backup recording etc.

It should have USB 3.0. Apart from that, just follow optimization guides for any USB audio interface (DPC latency etc.).

I noticed that you are researching adapters that are gPTP aware and support the other AVB standards, like the Intel I210. Keep in mind that this is just one part of what you need. You also need an ASIO driver, for example, which plays nicely with the adapter. An I210 by itself does not bring audio to the DAW.

With the cheaper switches, you don't need to set anything, it's plug and play. Once you connect the devices, they appear in the AVDECC Controller and all you need to do is set a media clock master, then connect the streams.

AVB streams require a LAN connection with AVB switches. The AVDECC discovery and remote control protocol itself is ok with any LAN connection, also without AVB switches. A web based remote control GUI as the M-32 Pro provides can be accessed via any network, including Wifi. You can connect AVB switches to non-AVB switches and routers, as long as the audio streams do not have to pass these non-AVB routers to reach their destination.

There are performance differences, but for a normal studio setup, let's say less than 150 audio channels and less than three or four switches, probably less than 30 streams, they do not reveal themselves at all. The reason for that is that any latency caused by a switch does not have an effect on the latency of the audio stream, which is defined as an offset by the 'talker'.

This offset (presentation time offset) is specified in the standard for seven switches at 100MBit (sic!) as 2ms, but in reality much shorter offsets can be set on 1GigE with fewer switches. That is why you can set the presentation time ('network latency') to lower values, for example 0.3 ms, if the talker supports it (RME devices do). The great thing about AVB is: if your network is too slow (ie. you have ten Switches in a row and try to set 0.3 ms), the stream simply cannot start (the receiver says: oups, that point of time has already passed, sorry!). If it starts, however, each switch along the way ensures that it will also stream when the network traffic increases, or the switches are experiencing extremely high traffic, and so on. No matter if it is a cheap AVB switch or an expensive one, as long as it is an AVB switch.

Example: a mic preamp establishes a connection to an M-32 DA Pro with a presentation time offset of 0.6 ms added to the gPTP time stamp of the samples. Since in an AVB network, both devices have the exact same time, they are fully synchronized to a couple of nanoseconds. The M-32 DA receives the samples with any latency that incurs on the network and then buffers the samples until presentation time specified by the talker. It is therefore possible to play the same impulse at the exact same time across different branches of a network, one stream only passing one switch, the other passing seven switches, without the switches causing delay or other issues. In fact, since AVB switches all reserve traffic for AVB when the stream is established, you can download Windows and Mac OS updates and upload to Youtube at the same time over the same network - the impulse will still be played out exactly at the specified time. If that cannot be achieved for some reason, it does not play at all. Haven't seen that happening, very unlikely because of the way traffic is prioritized and reserved in the switches.

You can benchmark a network with a Digiface AVB. It shows you how long it has to buffer ('input delay') the first incoming stream, and therefore it is very easy to compare two AVB switches or your network performance and guide you to the lowest offset setting.

Hope this cleared things up a little.

Max
RME

I do not think that the overhead caused by L3 is causing a significant delay by itself.

You create a handover point on one network to a L3 network protocol, which then sends via router to the next handover point in the second AVB cloud. While it would be possible to do some sort of AVB over L3 (there were considerations, I think it hasn't happened), I believe in such complex scenarios a bridge to AES-67 would be much more popular. And don't forget that AVB can peacefully coexist with L3 technologies on the same network.

Yes. As long as your in your AVB Cloud, you don't need to configure anything in the switches. Once you want to route across subnets over L3, you can put your IT hat on and get into the complexities of network administration.

A switch itself cannot encapsulate L2 AVB streams into L3 IP based streams. The abovementioned handover points could be designed like a dongle that you connect to your AVB-capable switch. It receives streams like any other AVB endpoint, translates them to Dante, AES-67, Soundgrid or whatever, and then sends the data to a L3 endpoint - and the other way round. Those kinds of devices will be more common in future, since network audio is not a battle where one protocol must win.
What the switch must support once the audio goes to L3 is a different story. Luminex switches are great for all sorts of network audio technologies, so if you aim to have complex networks, that's probably a future-proof investment (end of advertisement).

Yes, as I said, Luminex is great. Since we seem to be getting off topic here, let me just say that AVB standards are meant to automate and hide the complexities of IT network administration behind the scenes. It should be plug and play, and no user in the RME forum should ask how to set QoS or backup ports, spanning tree protocol and so on, especially not in SOHO setups. This forum is for recording, not for IT after all. A SOHO customer should never touch switch configuration, and never have to worry about black-lists and white-lists of recommended switches. That is maybe the biggest benefit of AVB - predictable, stable performance that scales without configuration or choice of switch manufacturer.

Just a quick note regarding redundancy:

STP and related mechanisms have been (and are still) discussed heavily within the AVB/TSN working group. However, Milan specifies redundancy just like Dante or Ravenna do: Having two separate networks where failover happens in the end points.

So while it is totally possible to have spanning trees (but requires quite some knowledge), the more practical and much easier way is to setup to independent networks with redundancy handled by end points.