[LAU] MOTU AVB discussion from LAC

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Sat Mar 30 21:40:23 CET 2019


On 3/29/19 4:56 PM, Max wrote:
> Fernando Lopez-Lezcano discussed the pitfalls of using the MOTU AVB 
> external audio interfaces with Linux in his paper [1] and also in the 
> keynote at LAC-19.

(I have to clarify that I have never been a fan of Motu and that Motu 
does NOT support linux - we happen to be able to use these cards because 
of class compliant driver support, to some degree, and the fact that the 
configuration is exposed through a built-in web server)

> Let's start another thread around this card.

(I'll add to the other messages as well... I started writing this last 
night)

> Fernando mentioned that different firmwares expose different issues, but 
> downgrading is possible. 

At least for now and in my experience. I presume that at some point the 
internal hardware might change in such a way that a downgrade is not 
possible. I think this has already happened for the UltraLite AVB. The 
Motu site lists firmware versions going down to 1.1.4, see:

http://motu.com/techsupport/technotes/firmwarechangelog/

I was not able to downgrade my UltraLite AVB to less than 1.3, a popup 
would tell me the firmware and hardware were not compatible.

So while everything described below, including downgrades, seems to be 
doable now (or at least the last time I bought an interface), that might 
change in the future with no warning.

> Issues are:
> 1. Channels are not persistent and swap around.

I have noted the following behavior on a 1248 with version xxx (sorry, I 
would to look this up at ccrma): route input to channel 1 - we see 
signal in channel 1, after a few seconds it appears in channel 9, then 
in 17 and so on and so forth. Downgrading the firmware cured this 
(again, I need to look up the current version running on that card).

> 2. Total number of channels has been reduced in newer firmwares.

The initial firmware I played with could only do 24 channels in CC 
(Class Compliant) mode, a firmware upgrade (1.2.8+) changed that to a 
max of 64 channels when using 44.1 or 48KHz sampling rate - the firmware 
adds a popup to the web based configuration to select max number of 
channels based on max sampling rate.

A subsequent firmware upgrade (1.2.9+) removed that feature - I filed a 
bug with Motu and was eventually told it had been removed because of 
unspecified problems. This is on the 16A, 24Ao and 24Ai, and maybe 
others of the same generation (8M, etc).

So if you need 64 channels 1.2.8+ is what you should use (based on my 
experience). If 24 channels is fine then newer firmware versions might 
be better (or worse :-)

If you are playing with that many channels you are probably going to 
chain audio interfaces together through AVB like I did, in that case you 
should check to see how many AVB streams are supported in the card of 
your choice. The 16A which I tend to use as hub supports 16 in 16 out 
(so at most 128 channels at one time). Other have less, the UltraLite 
can only do 3 at most. The 24Ao and 24Ai are asymmetrical (4 x 8 or 
visceversa).

> 3. An endless card aquisition loop between Jack and Pulseaudio caused by 
> the long time the card needs to switch sampling rate.
> 4. Seemingly erratic behavior, opening the device fails, fails again, 
> again, then works suddenly.

As pointed out in the thread I believe both 3 and 4 share the same 
cause, which is, AFAICT, related to the long time it takes for the clock 
to lock when the sampling rate is changed (or when the card is used for 
the first time).

ALSA seems to tell jack the card can do what jack requires (in terms of 
sampling rate, etc), and when jack tries to actually start it fails if 
the internal clock is not locked. Maybe there is no mechanism in ALSA 
that could be used to report or control this. I can't think of a way 
this could be handled that would work in all cases. What other software 
does when working directly with ALSA (Audacity) is to just play even 
though the clock is not running - the card will be silent until the 
clock locks and starts playing whatever is playing at the moment). Not 
optimal but a way around this.

The ALSA interface _sometimes_ (depends on firmware and interface 
model?) exposes a lock indicator that can be read from userspace with 
amixer. I currently query the interface with http+JSON and wait for the 
clock to lock before starting jack - this is on system that boot into a 
working diffusion system, not so practical for a stand-alone normal 
application (and needs an ethernet connection to the audio interface).

> I have a couple of questions and experiences.
> 
> Is there a table of the firmware versions somewhere (linuxaudio wiki?) 
> which tell me which versions has which features (removed)?

Not that I know of. See versions above for a start. I can add a few more 
data points when I go back to ccrma on Monday.

> Are all the Class Compliant models having the same quirks as listed 
> above? For example the
> MOTU UltraLite AVB versus the MOTU 624 AVB?

I have used the 16A, 24Ai, 24Ao (these three extensively used), 8M, 1248 
and Ultralite AVB. Also the 8A which is a different generation (USB3 
interface), this last one used to have problems - tiny clicks when 
playing back - but I think it now works fine (newer kernel?)

> Is it possible to use the Thunderbolt port to connect the card to a 
> Linux computer?

Not as far as I know. I did some research a while back and I remember I 
found nothing of the sort. This would require (I think) new drivers in 
the Linux kernel.

-- Fernando


> Why can't I tell ALSA to use only the first 2, 4 whatever channels of 
> the device? I can only open the device if all channels are connected. Is 
> this always like that or is that a limitation of MOTU's implementation?
> 
> On my laptop with only one USB bus, If I connected theĀ  MOTU 624 AVB and 
> then another high speed usb device, the computer could not connect the 
> later, because the MOTU reserved all the bandwith for itself. Connecting 
> the other device and then the MOTU worked.
> 
> [1] http://lac.linuxaudio.org/2019/doc/lopez.pdf


More information about the Linux-audio-user mailing list