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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
