[Jack-Devel] AVB

[Fernando Lopez-Lezcano]

On 2/24/19 4:00 AM, Jörn Nettingsmeier wrote:
> [sorry for the late reply to this one, I missed it the first time...]
> 
> On 12/31/18 1:04 AM, Fernando Lopez-Lezcano wrote:
>> 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).
> 
> Thanks for that hint. I'm about to get a MOTU for myself, so that's 
> gonna be useful.
> 
>> 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.
> 
> Owwww. That sounds _very_ bad. 

Yup, not the best.

> I'm currently experiencing a similar 
> problem on a Raspberry Pi when trying to cram 8 channels through a 
> stereo I²S line, 

Weird. Unrelated, right? How are you doing this, I presume you are not 
going through an alsa driver? (I would be interested to know more, I'm 
always interested in tiny computers that can drive many speakers or 
sample many microphone capsules :-)

> but I wouldn't have expected such things to come up in 
> professional equipment. 

I imagine that would not happen if you were to use their proprietary 
driver instead of the class compliant driver. In this case I did not 
investigate much, I just downgraded and it seems to work (I have not 
reported the bug). Probably our use case never gets tested.

> Well, as long as there is a known-good firmware 
> version...

There is.

>> 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 ... 

My latest _latest_ thinking says that what I said before is most likely 
wrong (like so many times before, ha :-). I think the whole thing 
happens on the Linux side, and is related to the USB interface. For 
example, I had forgotten I was running jackd with "-s" (long story about 
why that was there in the first place), once I removed that, things 
started behaving better.

I just finished stabilizing our new setup in our renovated Listening 
Room (you know the space :-), still 22 main speakers but now all Adams, 
and 8 Dynaudio subs instead of the old 4 - much much better sound 
quality. New (fanless) control computer redone from scratch, and an all 
Motu setup for driving everything.

Looks like it is running stable, 24x7, days on end with no glitches. 
Finally. The last problem was some kernel locking problem that 
apparently was happening between Supernova (the multi-core aware 
SuperCollider sound server) and aconnect of all things. I was calling 
aconnect from SC to detect changes in connected midi peripherals and 
sometimes this would (apparently) do bad things and the whole thing 
would grind to a halt. I switched to monitoring midi through /proc/ and 
that apparently did the trick.

> Do you know whether the different AVB MOTU boxes are all the same in the 
> way they handle AVB (as in, identical subsystem/firmware/drivers)? I'm 
> eyeing the one with eight mic preamps (MOTU 8 Pre-es)...

They all talk to each other as long as they are AVB (so far...). We do 
have one MOTU 8M (the one w/8 mic preamps) in the Listening Room and it 
is happy (we use its usb2 interface as the gateway into the system for 
external laptops). It is connected through AVB to one 24Ai, one 24Ao and 
a 16A which is where the control computer connects through USB). In the 
Stage we have 8 MOTU cards talking to each other (+ 3 MOTU AVB switches).

>> 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.
> 
> That's very good to know. Does it have a sane documented interface, or 
> are you basically reverse-engineering the mixer website?

It is documented...

For OSC there is this (I have not tried osc):
https://cdn-data.motu.com/downloads/audio/AVB/docs/OSC%20Quick%20Reference.pdf

For http+JSON:
https://cdn-data.motu.com/downloads/audio/AVB/docs/MOTU%20AVB%20Web%20API.pdf

Carlos (sysadmin here) sort of reverse engineered how to get a full 
preset from the data stream so we could capture those and resend them on 
demand. We are using http+JSON (form SuperCollider) to both read 
internal status (for example querying the master clock audio interface 
to see if its clock has locked[*]) and to change stuff (for example 
change the connection status of a crosspoint in the internal switching 
matrix of an audio interface)

...
>> 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.
> 
> I've been lurking on the open-AVB list for a long time, nothing much 
> happened. 

Same here, a few posts here and there that seem interesting but nothing 
that solves the whole problem (which is complex).

> Then I talked to an AVB guy with Meyer Sound at the last 
> Tonmeistertagung, they just renamed everything "Milan" and are seriously 
> getting off their asses now (probably panicking about the Dante camp 
> just having announced basic video capability). Loads of new products, 
> finally talk about cross-vendor interoperability and interesting 
> plugfests (they showed Meyer AVB gear talking to Shure wireless units 
> and some professional power amps by another brand). Let's hope some 
> crumbs fall into the land of free software.

Crossing fingers here... I'm itching to compile and start testing, no 
time yet.

The MOTU is a reasonable option _now_ if you are aware of the caveats, 
but I have not much faith in the future given my experience with their 
firmware. At some point (hopefully very very far in the future) the 
internal _hardware_ will change - probably sporting the very same model 
number - and then we will not be able to downgrade firmware in really 
new boxes (I have seen that in the UltraLite AVB I have, the really old 
firmware versions for the card in their web site do not load in my 
UltraLite). If what is lost is the 64 channel mode that I need then: 
dead end again.

The best would be to talk AVB from Linux.

Or maybe reverse engineer their proprietary USB endpoints and adapt the 
Linux USB driver to be able to handle those? Or clean-room 
reverse-engineer Dante itself? Or be really _really_ smart and make 
music that only needs one speaker! (or one microphone capsule). Mono and 
Omni! YES!
:-P

-- Fernando


[*] nasty things happen otherwise, the MOTU takes 5 or 6 seconds to 
stabilize its internal clock when switching sampling rates or when 
_first_ using the interface after a reboot. ALSA sees the interface all 
the time, and Jackd also sees it. But if you try to start Jackd while 
the MOTU is not yet locked... Jackd starts but then fails when it 
(maybe) realizes the card is not yet ready. If you are patient and wait 
a few more seconds and then try again jackd starts just fine.

For fun: have pulseaudio running and set to 44.1KHz, try to start Jack 
at 48KHz (and repeat if not successful)....

0: jackd starts, gets the card from pulseaudio
1: jackd switches the card to 48KHz (while starting)
2: jackd fails to start because the card is not yet ready (unlocked)
3: jackd gives the card back to pulseaudio as it quits
4: pulseaudio switches the card back to 44.1KHz
GOTO 0

Infinite loop!
Infinite fun!

More fun: have a MOTU card in 64 channel mode in a modern pulseaudio 
environment (Fedora 28, for example). Pulseaudio does not like the card 
as it has > 32 channels. It does NOT ignore the card. It thinks the card 
will be better behaved magically in the very near future as it tries 
again and again to use it (lots of messages in the logs). Jackd cannot 
"borrow" the card from pulseaudio. Jackd cannot start on that card (tip: 
I run out of patience so I just told pulse to ignore that card).