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.
surprise.
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,
etc.)
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
DE.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
