Linux AVB Support

How can it be that Linux AVB Kernel support is virtually nowhere to be found on i386/amd64 platforms ?

What is preventing the development of official openAVB support (with Inter i210 nic) to make use of the so far released AVB devices out ther. Modu AVB, Presonus AVB and others ?

I would love to be able to set up a dedicated AVB PC box to stream AVB streams to and from my AVB devices but that doesn’t seem to be happening very soon.

If Qjackctl could show possible AVB streams on the ABV net and also help connectiong streams to Ardour, things would be awesome.

As a non developer, I imagine everything is IEEE standards and presumably well documented so that’s why I ask.


I realize I’m a bit late to this thread, but I am interested in helping make AES67 more of a reality for Ardour and Linux in general. Ccaudle: is there a way I can help collaborate with you on the code you have? With all of the Dante devices around that claim to support this protocol, I think this can only be a good thing. There certainly is more support for this than avb currently.


AVB streams can be connected to jack. However, the process is very much manual and command line oriented. Linux audio gets developed by someone having the box and deciding to make it work. Most of the AVB boxes out there have to work with windows to be worth producing. So they include a USB port as well. This means the Linux user can use the USB port as well. So from Linux users POV, they can plug in to usb or… they can buy a new i210 NIC and AVB switch. This would cost as much as the AVB interface has already cost. So there is extra cost money wise and then there is all the work in getting something to work that already works just as it came with no work. Basically there is no real incentive to work on it. As for having qjackctl support AVB streams… buy Rui the boxes and it might show up. other than that, not likely to happen (maybe not even then) Jack and AVB are very different beasts. Jack expects all ports to be live all the time even if not connected or silent. The AVB stream is only available until a connection made, not active. Making a GUI that deals with AVB connections would be as much work as qjackctl all over again. AVB in general doesn’t just connect one port either, to connect one port a stream of 8 ports has to be added. It is like connecting another whole audio interface. Jack doesn’t think that way :slight_smile: I have two i210 NICs and could set up an AVB audio link between to machines, but to really make use of AVB I would need an AVB audio IF and a switch… not in my budget any time soon.

Also missing from linux AVB… the i210 is a good start, but what it lacks is some way of giving jack or even the local sound card a sync signal (word clock or even s/pdif). The i210 would run a precise time server internally. but jack needs to use the same clock and so does the local audio card for AVB to work. Really, there is no computer HW that does this except AVB audio cards that cost too much. The i210 does have some pins that could be programmed with some sort of clock but would require external circuitry to make it usable. Not something that is doable for the average user.

I agree on most points…

I recently tested netjack to stream things between computers just for offloading dsp on my main system and did find it quite useful. Having two AVB cards and no switch, I was thinking about getting an AVB switch but would also like to run true AVB on one of my boxes and keep that box in a separate location away from my studio. USB cables are not easily extended to 100m

Anyway, The concept with global precision timing for all devices in a domain combined with sub mS latency is too good to be ignored imho so I hope AVB eventually gets supported all the way in a user friendly way through Alsa or Jack or even Pulse… or maybe pipewire

An Intel 210 nic will not let me hook up to my Motu AVB streams easily or not at all, you say


“An Intel 210 nic will not let me hook up to my Motu AVB streams easily or not at all, you say” I don’t think I said that quite, though it may sound that way. The real answer is that I would like to have a MOTU AVB box to try to be perfectly honest. But it is not in the budget for now. I do have two i210s and will at some time try running two linux boxes in stream.

The problem with jackd and AVB at this time is that jackd does not expect the number of ports in it’s audio interface to change and so it would be hard to make an AVB backend for jack. So AVB streams are connected as clients. In order for this to work one of two things has to happen: A) whatever backend jackd is using has to be in sync with the AVB clock. That is either the dummy backend has to be in sync with the i210 (maybe possible) or the audio IF the back end uses has to get wordclock from a device on the AVB net. B) use sample rate conversion in between AVB and jackd in the same way as alsa_in/out or zita_ajbridge do.

There are no Audio interfaces I know of that allow themselves to be synced programatically in Linux (I think there is one RME that has the signals but no driver in linux… or windows) So clock sync would have to be external.

It would be possible to create an AVB jackd backend. It may even be possible to make it work without the i210, but the i210 would be better. It would be possible to create an AVB alsa driver/module too… though harder I think. The jackd method just makes more sense as it allows stream connections to be made after startup. I think the way to go is to start with the jackd dummy back end with some dummy ports and relying on the timer in the i210. When a stream is added it would be connected as a client but would not need SRC as it would still be in sync. Even nicer would be if the first stream connected would take over the dummy ports in the backend so the there are some standard “system” ports. A GUI mashup that combines a jackd style connection grid with “possible connections that would become jackd ports if enabled, and then connected” would be really nice. However, until there is a jackd backend for AVB creating a GUI is not worthwhile IMO. The i210 driver would have to be able to be it’s own master clock if there are no devices connected for this to work ( I think it does already).

If the use case is static, that is the number of streams will be the same from jackd startup to close, an AVB backend might be easier.

The problem with jackd and AVB at this time is that jackd does not expect the number of ports in it's audio interface to change and so it would be hard to make an AVB backend for jack.

While I have limited experience with AVB, I extensively use Dante and a page could be taken out of the Dante Virtual Soundcard approach, which is you don’t change them, you provide a set number of ports at startup, and then it is on the client to handle routing to those ports, but the driver always only allows a set number of ports (from 8x8 to 64x64 in your standard multiples).

Dante Via works a bit differently though. Not sure how AVB works honestly at this point, rarely use it.


The lowest cost AVB DAC would probably be this (DAC only, does not include ADC so you cannot record with it):
US$300 for an 8 channel DAC, single ended I/O, no balanced option

Switch chips with AVB support are getting relatively inexpensive, but there doesn’t seem to be much support in end devices (likely because of the software complexity). The 5 port MOTU switch is probably using one of the small Marvell devces, Linksys or Netgear could put one of those devices in a home router, but if they have it does not seem that they have enabled the AVB software support. MiniDSP has a device you can buy for US$120, but it is a bare circuit assembly, no case, so definitely a hobby type of project, not a turn key off the shelf solution.

However, you can use a single AVB device in a point-to-point connection with no switch, so if you have to add in a new Ethernet card anyway, assuming your machine already had an Ethernet or WiFi connection you could just treat your new AVB compatible NIC as a dedicated port. At which point you are back to no better off than using USB except for the much longer distance limit (ca. 100m instead of 10m or less).

"the i210 is a good start, but what it lacks is some way of giving jack or even the local sound card a sync signal "

The clock for jackd would need to be derived from the PTP sync, that is a fundamental point of AVB synchronization. Basically a software clock creating interrupts at the appropriate time instead of relying on interrupts from a hardware sound card. For a local sound card to play back the AVB streams you would need to use zita-a2j and zita-j2a, the equivalents built in to jackd v1, or alsa_in and alsa_out plugins, in other words the same as digital audio has always been, you either synchronize to a common clock or you have to use sample rate conversion as a way to move the audio from one clock domain to another. The AVB interfaces all synchronize to the PTP clock, so having an AVB interface and also trying to use another interface is really the same situation as trying to use a PCI card interface and a USB connected interface together, you either make a clock connection to synchronize or you have to use an SRC adapter.

The biggest advantage for AVB is the automated bandwidth reservation, automatic priority control, etc. that makes sure enough switching bandwidth is available before letting a device join, and making sure that general network traffic does not block the media traffic. With a little bit of knowledge and manual setup of VLAN and service priority you can configure a managed switch to get pretty close to the same performance, which is what AES67 compatible protocols rely on. That doesn’t require specialized switches, just mid-range business class switches for shared network use, or even a pretty low end switch if you are willing to have separate switches for audio use and for the rest of your Internet and general local network traffic. Audinate has an AES67 compatible mode for Dante devices now, SMPTE is standardizing on AES67 audio transport for the new video over IP standard. It seems at least for the pro market that layer 3 transport is going to win out over the layer 2 AVB transport.

Unfortunately AES67 support on Linux isn’t in much better shape than AVB. It potentially could be.
I got access to a virtual ALSA driver for AES67, but the developer wasn’t really keeping up with Linux development, it would not compile on current Linux kernels, a couple of API had changed so it only worked with kernel versions up to several months back. The driver was marked GPL but was not on a public repository. Supposedly it was going to be released publicly at some point, but I have not heard anything more of that. I started working on fixing up the API use so it would work on current 4.14 based kernels, but that is somewhat tedious without a public git server to work from.

Someone else was working on a jackd client to support AES67, but that has been delayed by other paid work that had to be prioritized. I expect that still will happen in a few months.

The hardware interface situation for AES67 compatible devices is not not really any better, only a couple of Ravenna interfaces are available at what I consider to be pretty high prices. I prefer Ravenna because of the completely open specification, but even if you are willing to go with Dante in AES67 mode to avoid the proprietary licensing hassles of original Dante, the available devices are pretty expensive. So not something you would choose over USB for home use.

I really wanted Ethernet connected interfaces to become the new available everywhere kind of interface, but it just doesn’t seem to be happening. For now that is still USB with the limits that go along with that (limited distance, no standard way to synchronize multiple devices except external word clock, problems associated with hub design rather than packet switching, etc.). Maybe it will get there eventually.
If anyone wants to donate a Merging Technologies Hapi interface for me to play with, I will gladly help make it happen faster. :slight_smile:

Good to see people have insight in the ways AVB support could be implemented.

@seablade AVB typically uses streams of 8 Channel blocks. My Ultralite AVB cards can handle up to 3 in and 3 out (24+24) If i want to use AVB streaming I have to select number of in blocks and out blocks. Better Motu card can handle 64+64 or 128+128 Channels typically

What I personally hope is that AVB will gain market share and be a real (and open/royalty free) alternative to Dante and include Linux as true AVB nodes.

The automotive industry seems to be the most serious adopter so far.


Personally at this point I would rather good support for something that allows for AES67 compatibility rather than just AVB in particular. AVB the downside is the need for some more specialized chips, where as Dante I can run off of the shelf hardware in comparison in many ways. Given that Dante is far more prevalent in the install and touring market these days, it would be far more useful to make sure we could interoperate with it (AES67 compatibility) than anything for me, as then I could track off a live console, etc.


^ Designs said live and install systems, in fact currently waiting in the parking lot of a potential client for one as I arrived a bit early:)

dante will also connect with or show up on AVB networks. From a linux home studio on the cheap point of view… aes67/Ravenna is completely open so long as you wish to pay AES of course but there seem to be no open projects. AES67 seems to be a broadcast format that broadcast equipment manufactures have embraced but has not come near the recording studio. As mentioned the prices are only affordable by the likes of ABC, BBC, etc. Certainly no one making small inexpensive home audio interfaces has mentioned aes67 unless they are making a dante box. Dante boxes are also expensive, I am guessing because they are aimed at the “next level” of home user above the basic USB box. And because dante is not interested in Linux and it is closed… it is of little interest. I do not know how well it talks with AVB devices. That is it maybe that a dante network will deal with AVB endpoints but dante end points will not be seen on an avb net.

What has really changed the networked audio world for the home Linux user has been MOTU’s AVB line. They are priced within the USB interface range and do work as a USB interface (or thunderbolt if Linux supports that) so even if it can’t connect directly to ethernet out of the box, it is usable and expandable via AVB. There is an open AVB project that includes Linux drivers and jackd clients for both input and output. So in theory (I don’t know of anyone who has used a MOTU box with these drivers) it should “just work”. The main players in the open AVB code have been intel and audioscience (that I recognize) and the audioscience git fork hosts a utility (command line only) that allows routing AVB boxes on a network. It lists all available AVB endpoints and their available streams and allows connecting one to the other. That would be the place to start for me.

The other possibility as mentioned is the minidsp stuff. This is not end user friendly as it is bare boards and in some cases does not include the codecs. And by the time one paid $300 for half an IO… the MOTU stuff looks cheap. for the same $300 looks a bit better and uses 1000mb net as opposed to only 100mb. xmos used to have cheap endpoints as well for two, but support is ended and they are only stereo (and only 100mb). xmos used to have a switch as well, but I can’t find them anymore and they were 100mb as well.

I have just noticed that presonus has started doing AVB and offers a switch (much like the MOTU switch) and uses AVB as transport for some of their mixing consoles so something like may be of interest though $800 is a bit much compared to some of the MOTU offerings. However, it does seem to point out that AVB seems to be the choice for manufactures who have traditionally offered USB boxes. (And haven’t already invested in dante :wink:

One more thing that should be mentioned is that sub ms latency was mentioned above. While AVB does support very low latency, it seems to me that the MOTU boxes are 1ms (16/3 in jack terms) and that goes well with aes67 if they are bridged. The reality is that 1ms in a linux box is a struggle no matter how well the interface supports it. DSP and CPU go way up and there are some plugins that just won’t deal that low anyway. The latency across the network is good, that is frames from one box on one side of the network will line up very well with a box on the other side of the network. However realistically, the latency from net to audio application will probably be 2ms minimum.

Len, I see several things that I think are misunderstandings on your part. Possibly I am working on outdated or partial information as well, but in order of your posting:

“dante will also connect with or show up on AVB networks.”

Audinate stated that as a goal at one point, but as far as I can tell the Dante protocol was never updated to work with AVB. The original version of the protocol works with licensed Dante devices only, the latest update works with AES67 compatible devices. Both versions are layer 3 protocols, with the biggest difference being a shift from IEEE 1588-2002 (PTPv1) clocking to IEEE 1588-2008 (PTPv2) clocking, and a change of encapsulation from custom UDP packets to RTP packets for compatibility with AES67. AVB specifications include provision for layer 3 encapsulation using IEEE 1733, but so far all implementations that I am aware of use IEEE 1722, i.e. directly in layer 2 Ethernet packets with no IP header, so will not be directly interchangeable with layer 3 based protocols like Dante and Ravenna.

"aes67/Ravenna is completely open so long as you wish to pay AES "

AES only charges for copies of the specification, and only if you are not a member. An AES member could purchase a copy and give it to you, you would be free to implement with no charges (as opposed to Dante where my understanding is you have to pay per device royalties if you want your device certified and branded as a “Dante” device).
In fact, AES67 isn’t really a stand alone protocol, it is an interoperability standard that describes the settings you need to support to allow operation between existing standards. Not all of the existing protocols supported the intersection of features needed, which is why you have things like Dante v2 which changed from PTPv1 to PTPv2. With minor updates like that you can now exchange data between Livewire, Dante, Q-Lan, and Ravenna devices. You have to choose the intersection of settings supported, and the discovery and connection process is not standardized so getting the different dialect devices connected is a more manual process then when you stay natively in one protocol, but the point is AES67 isn’t some new thing, it is basically describing a compatible subset of several existing protocol designs, and uses standards already published by IEEE and IETF.

And of course Ravenna has no charges even to download the specification, just go to and download the docs. AES67 is a subset of Ravenna, so if you implement Ravenna your design will be AES67 compatible as long as you choose settings which match the connecting device.

“AES67 seems to be a broadcast format that broadcast equipment manufactures have embraced but has not come near the recording studio.”

I would agree that mostly broadcast equipment manufacturers have implemented first, but the Merging Technologies Horus and Hapi devices are definitely studio class devices. There is no reason that the protocol would not be applicable to studio use, but like MADI it is starting out just in pretty high end applications. MADI stayed there, I can’t tell yet whether audio over IP will stay at the high end only or come down market. I suppose you could argue it has already come down to the mid-market level with things like Focusrite Rednet Dante devices.

“There is an open AVB project that includes Linux drivers and jackd clients for both input and output.”

Did that ever get to a usable state? The last time I looked it didn’t really look finished.
Are you talking about these?

I don’t think that there should be any reason preventing sharing some of the low level plumbing in an implementation that can support both layer 2 and layer 3 operation, but it doesn’t seem likely that one developer would have enough hardware to work on both unless sponsored.

Both of the projects I mentioned previously (ALSA virtual device and jackd client) are being developed by people at commercial firms. One does not seem very serious about LInux, seems to be dabbling, one is very Linux focused and stated an intention to have a demonstration working of jackd connected to AES67 devices (probably Dante) by the NAB conference the second week of April, so we’ll see if they make that.

1 Like

@ccaudle pretty much summed it up, thanks.

ccaudle, I don’t know how close dante to AVB bridging is or was, the sound of the bit I read on their website made it sound done at least if not released and that was some time ago. In any case, dante will not work with Linux so it is probably of little concern.

I am not sure what the difference in paying aes for stuff is between what you said and I said, yes it is pay once to get the spec… either pay to be a member or pay by each spec. Any time I went to the Ravenna site and tried downloading anything, I got asked for login, unless that has changed, that route is not exactly free and open either. (though maybe without monetary cost) I was able to DL all the links you gave and will look through what else I can get on their DL page, thanks.

Really, I would be happy to see any and all network transports supported by Linux and I would like to see Linux able to do bridging as well between the two.

It has been a while since I looked at the horus and hapi, but at the time I had a difficult time seeing a use for either in my studio and they seemed over the top price wise for what they provided. I would tend to a cheaper (or at least similar) PCIe (16io) card or two. In truth my wants have changed since I have looked at these devices and where I dreamed of high io counts before, I have found that for most of my work, one or two inputs has been all I needed. Room for a drum set would change that though :wink: However, because of the entry cost of aes67 devices, I can see why there is not much push to develop a Linux driver. It would help some people but not many. I have not heard of any of the linux users I have talked to that owns and aes67 audio interface whereas I have heard of a number of people (over a half dozen anyway) who have AVB capable motu boxes. Having said that, I would guess there is a significant number of broadcast Linux users so perhaps there is reason for aes67 just from the POV.

Again thank you for some of the nudges, I will reread the bits of ravenna files you gave and see if it is possible to get some thing from that. I have finally installed one of my i210s in a box which is probably good for either aes67 or AVB with its hw (firmware?) clock in it.

Both aes67 and AVB seem to have a lot of other standards that have to work first or as a part of them. For a setup where there is already a large investment in network infrastructure (such as broadcast) aes67 looks good. If you have next to nothing and have to buy switches anyway… AVB looks like less of a burden to get going (like a home studio). If having Linux is a don’t care then dante is probably more flexable right now.

There has been an attempt to get an AVB (TSN) driver into the kernel (google for TSN driver).

@ccaudle How up to date are the documents pointed to above? Ravenna in it’s web site claims full aes67 capability, but in one of the papers (written before 2014) says not. That is it shows itself being fully capable in the mutlicast area but not in the unicast area as it does not (maybe did not?) support SIP natively. I don’t see this as a problem for Linux at least not to start. The main uses of studio or live multitrack recording would be all multicast anyway. There is more work being done on AVB with an eye to creating a SW AVB/TSN ALSA “device” with a set number of ports that other AVB ends could be connected to. I would suggest that may be the best way to deal with aes67 as well. (load the kernel driver with a parameter for port counts)

I think the unicast/SIP part of aes67 was added to fit in with the EBU tech3326 standard which uses SIP for connections for remote contribution already. This allows reporters with a phone access as well as phone show kinds of things with almost no addition. They do add more mandatory codecs than aes67 though.

Assuming any new rednet devices would also support aes67, this may be the least costly aes67 interface out there:
Still $900 is getting up there for a 2x2 I/O box. The xnode (8x8 line level or 4x8 with mic pre) is only 1500 SLP ( ) for more than twice the i/o.

“How up to date are the documents pointed to above?”
@lenovens: As far as I know the document describing Ravenna protocol (the operating principles draft 1.0 doc) is up to date, I have not heard anything about Ravenna revision since it first went live. The other documents will vary, some are presentations and so anything relating to adoption numbers will depend on the date, any comparisons to other protocols will be accurate only insofar as there have not been updates to those other protocols, etc.

“Ravenna in it’s web site claims full aes67 capability, but in one of the papers (written before 2014) says not.”
Can you give some context or citation? The guys behind Ravenna were very involved in the AES67 standardization work, in general Ravenna should be a subset of AES67. You have to manually select a configuration which is not using some feature that is not included in AES67. AES67 is an interoperability guideline, so it is kind of the intersection on a Venn diagram of various features of existing protocols, or in the case of Dante (original) almost intersection, and Audinate was able to modify their existing protocol just a little to interoperate (I think primarily changing from 1588-2002 to 1588-2008 synchronization).

“That is it [Ravenna] shows itself being fully capable in the mutlicast area but not in the unicast area”
The Ravenna spec is that “RAVENNA nodes MUST support multicast and SHOULD also support unicast.” Dante is kind of the opposite, it defaults to unicast but can be configured for multicast. I don’t have a copy of AES67 in front of me, I know it mentions multicast and unicast, but I don’t know the must vs. should wording in the AES spec.
The document “AES67 and Ravenna in a Nutshell” states it as:
“Since the AES67 specification is very close to the RAVENNA Generic Profile, it can be expected that all RAVENNA-enabled devices supporting the RAVENNA Generic Profile can also support AES67.” …
“Since the RAVENNA framework allows for extensions and protocol variations beyond its core definition, SIP can easily be added as an ingredient for the RAVENNA AES67 operating profile. In other words, RAVENNA devices continue to use RTSP/SDP connection management, while SIP will be used when communicating to other devices under the AES67 operating profile.”

“I think the unicast/SIP part of aes67 was added to fit in with the EBU tech3326”

I don’t think it was to fit in, since the AES67 uncompressed audio low latency use case doesn’t really mesh with the compressed audio and remote contribution use case for 3326, I think it was more a case of re-using existing software. And actually 3326 has multicast operation as a “should,” so really SIP is the big difference. All the different protocols used different connection setup and control methods, so the X192 committee had to find something that was the closest to working for all.
This is a pretty good comparison table:

Dante only supports multicast according to the Yamaha documentation included in that issue. Since Dante support seems to be the main reason people would like aes67 support… that document would seem to be a good place to start. Multicast seems to be the lowest point of entry that supports almost everything.

Dante supports Unicast as well, in fact while I haven’t confirmed on recent systems, for a long time I had to specifically make multicast flows for Dante to improve network performance in more complicated systems.