[LAD] AES67 Audio over IP and JACK

Len Ovens len at ovenwerks.net
Sat Jun 12 22:39:44 CEST 2021

On Sat, 12 Jun 2021, Julian Rabius wrote:

> Now thanks to A. Bondavallis initiative a fully open source 
> implementation of AES67 on linux, which opens up possibilities for 
> audio-networking with lots of professional grade audio hardware devices 
> and computers running different OS seems to be very close.

sounds good.

> Unfortunately the developer does not seem to be an active user of the 
> jack ecosystem, nor ardour or other typical software for 
> audio-production on linux.


> Though with basic alsa tools the AES67-daemon already seems to work 
> flawlessly, I had no success starting jack or ardour on top of it.
> There was some discussion on this topic in the following thread, but to 
> my impression more research into compatibility with jack, ardour etc. 
> would be necessary.
> https://github.com/bondagit/aes67-linux-daemon/issues/38

My opinion in this case, is that the best way in Linux to deal with aes67, 
dante (probably via aes67) or AVB, would be to create a backend for jackd 
similar to the dummy backend that gets it's timing from the network media 
clock. This would allow the same instance of jack to create end points 
for both aes67 and avb at the same time. AES67 or AVB could then be added 
as jack clients much the same way that alsa_in/out or zita-ajbridge does 
now except without needing SRC. The available Linux bits for AVB are 
already jack clients though I am not sure if the backend is forced to the 
network media clock in that case.

My reasoning for adding these network protocols as jack clients is that 
network audio is not static and the number of end points can change at any 
time as new end points are added and others are removed. ALSA and jackd do 
not deal well with nonstatic port counts in "devices" while jackclients 
can add and remove ports easily. There is also the need to be able to do 
network side routing. that is, assuming some number of ports in a jackd 
client, they may be connected to a user selected set of available end 
points in the network. For the home studio that has one aes67 or AVB end 
point this may sound over complex but larger venues with more complex 
setups might absolutely need it. (radio/TV stations, stadiums, theators, 

The pipewire dev while experessing some interest in supporting network 
protocols, probably will not get to that for a while. But pipewire does 
support using jackd as a "device" and like pulse (but better), presents a 
default alsa device to applications that want that. If that application 
open the pw alsa device with the same sample rate/buffer size, there would 
be no SRC with that route either.

Pipewire looks to be the next thing in Linux audio, replacing pulse and 
jackd while presenting applications that need those APIs with the ability 
to connect directly to it and there for the device. This already works, 
though as many people will point out, pipewire is not ready for primetime 
(semi) pro audio just yet. None the less, do expect it to show up in one 
of your next upgrades in the next few years as the audio server for your 

Len Ovens

More information about the Linux-audio-dev mailing list