Re: [Jack-Devel] AVB

On 2/24/19 4:00 AM, Jörn Nettingsmeier wrote: Yup, not the best. 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 :-) 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. There is. 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. 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). 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.… For http+JSON: https://cdn-data.motu.com/downloads/audio/AVB/docs/MOTU%20AVB%20Web%20API.p… 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) ... Same here, a few posts here and there that seem interesting but nothing that solves the whole problem (which is complex). 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).