[Jack-Devel] AVB

[Fernando Lopez-Lezcano]

On 12/22/18 12:40 PM, Jörn Nettingsmeier wrote:
> On 12/8/18 2:37 PM, Christoph Kuhr wrote:
>> On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend.
> 
> I would say that for now, if you need to speak AVB, the easiest path is 
> to get a recent MOTU USB class-compliant device with an AVB port. That 
> way, the Linux system only needs to concern itself with the USB audio 
> part, and the routing in the MOTU connects you to the AVB world. 
> Thankfully, after being quite useless for open-source for many many 
> years, they've now made two good decisions:
> * USB class compliance, 

Yup, that is exactly why I was able to use Motu in my latest systems in 
the fashion you suggest (out small Stage concert hall now has a 56.8 
system, and our 3D 22.4 Listening Room has new speakers and Motu based 
control system).

Class compliance vs linux comes with some caveats (at least in my 
experience)...

If you need more than 24 channels (I use the 64 channel mode) you need 
to downgrade your card to firmware 1.2.8+ (this is true for the 16A, 
24Ao/Ai and 8M, AFAIK). 1.2.9 onwards does away with that mode so you 
are restricted to 24 channels max in class compliant mode (which may not 
be a problem for most users).

Even then I found problems with the latest firmware version, input 
channels would shift in blocks of 8 every few seconds (ie: input coming 
in through channel 1 would suddenly appear in 9, and so on and so 
forth). Again, downgrading a bit gets rid of that problem.

So, not so nice. Firmware giveth, firmare taketh away (with no warning)...

The story does not end there, there are conditions in which changing 
load in the Linux computer has effects in the AVB domain, specially if 
the Linux computer is pretty loaded (either a glitch, or the interface 
starts making some low level buzzes or distortion every second, or so, 
sometimes temporarily, sometimes it gets stuck in that mode). My latest 
thinking is that the internal processor of the Motu interface must be 
close to being fully used, so when there is some glitch in the timing of 
the USB packets it affects the rest of the internal processing, 
including AVB transport. Just doing some tests a couple of days ago, 
seems to also depend on number of AVB streams being used. But this is 
just speculation on my part, no facts (facts are overrated these days, 
argh).

> and
> * the masterstroke, i.e. implementing the mixer as a web server that can 
> be accessed via any browser, thus relieving open-source developers of 
> the tedious task of reverse-engineering a mixer that will then only work 
> on one particular device.

Yes definitely very very nice.

You can even control most of the internals through http+JSON or OSC and 
we do that to control the internal routing matrix and modes in our systems.

> Christoph, would you agree, or can people who do not frequent the same 
> circles of hell as you are so competently doing consider "native" AVB 
> yet? I've been lurking, but mostly been very, very afraid :)

I'm forever wanting to do the full AVB stack, never find the time. The 
is now even a branch in the OpenAVnu project that apparently can use a 
non-AVB ethernet interface. I did some tests a while back and managed to 
get Linux to sync to an AVB Motu card, and the card would switch into 
"AVB mode". Never went further than that.

-- Fernando