9 Mar
2021
9 Mar
'21
10:09 p.m.
Hi list,
I am wondering if the Motu M64 Madi audio interface is class compliant
or not. The only information I found so far is Paul Davis mentioning it
was not on https://discourse.ardour.org/t/usb2-3-madi-adat/88392/13
Nevertheless I plugged one in today and was able to select it as a
device in qjackctl but did not get jackd to start using it. I had very
little time and forgot to take logs and messages.
thanks for all hints!
P
9 Mar
9 Mar
11:25 p.m.
On 2021-03-09 14:10, Peter P. wrote:
I am wondering if the Motu M64 Madi audio interface is
class compliant
or not.
Use lsusb to display all the USB devices, after you know the bus and
device number for the M64, use -v and -s to display verbose messages for
that particular device (the argument to -s is bus_number:dev_number).
Email that information to the list, probably someone will be able to
help interpret how the device is presenting.
--
Chris Caudle
12 Mar
12 Mar
7:42 p.m.
Hi list,
can report that the Motu M64 Madi interface does work with a limited
channel count of 24 for input and another 24 for output (instead of 64
each). So if you are coming across a venue or employer that already has
one, you are good to go. Sample rate needs to be set on the device
before starting jack. Of course, buying the card for oneself for so much
money getting only one third of the channels seems useless linux users
IMHO.
cheersz, P
* Chris Caudle <6807.chris(a)pop.powweb.com> [2021-03-09 22:25]:
On 2021-03-09 14:10, Peter P. wrote:
I am wondering if the Motu M64 Madi audio
interface is class compliant
or not.
Use lsusb to display all the USB devices, after you know the bus and device
number for the M64, use -v and -s to display verbose messages for that
particular device (the argument to -s is bus_number:dev_number).
Email that information to the list, probably someone will be able to help
interpret how the device is presenting.
--
Chris Caudle
8:12 p.m.
On 2021-03-12 11:43, Peter P. wrote:
can report that the Motu M64 Madi interface does work
with a limited
channel count of 24 for input and another 24 for output (instead of 64
each).
That seems misleading on the part of MOTU. There is no mention of that
anywhere on the product web page, and the readme file for the "pro-audio
driver" even has this note:
USB audio class-compliant operation on macOS
All of the MOTU interfaces listed on page 1 of this document are USB
audio class-compliant on macOS. This means that you can connect them to
any Mac running macOS 10.11 or higher using USB for multi-channel audio
I/O without having to install any drivers.
No mention of reduced features when using class-compliant operation.
Is that actually a device limitation, or a linux usb audio driver
limitation?
--
Chris Caudle
10:40 p.m.
I have three Motu devices and Motu have changed their CC USB stance to only
allow 24 + 24 streams over usb.
This happened a long time ago with a firmware update for Ultralite AVB
which did support 64+64 when running 44k1 or 48k.
Newer models of Ultralite does not support downgrading to older firmware
that supports more than 32 streams.
The same seems be the case with my Motu 24ai and might be true even if
running native driver for Windows or MacOS (have not tried) Motu 24ai
supports 72 channels + avb streams so I'm total. Close to 170 channels so
the limited USB support really cripple the usage.
I have repeatedly been I contact with Motu support and the state they love
Linux and promises things will improve but so far there has been no proof
to back it up.
Motu has not changed the documentation regarding these limits and I have
pointed out the fact that they are advertising stuff that is no longer true
but they promise to fix the documentation but it is all just talk.
I would say, stay away from Motu if possible.
Regards
On Fri, Mar 12, 2021, 19:13 Chris Caudle <6807.chris(a)pop.powweb.com> wrote:
On 2021-03-12 11:43, Peter P. wrote:
can report that the Motu M64 Madi interface does
work with a limited
channel count of 24 for input and another 24 for output (instead of 64
each).
That seems misleading on the part of MOTU. There is no mention of that
anywhere on the product web page, and the readme file for the "pro-audio
driver" even has this note:
USB audio class-compliant operation on macOS
All of the MOTU interfaces listed on page 1 of this document are USB
audio class-compliant on macOS. This means that you can connect them to
any Mac running macOS 10.11 or higher using USB for multi-channel audio
I/O without having to install any drivers.
No mention of reduced features when using class-compliant operation.
Is that actually a device limitation, or a linux usb audio driver
limitation?
--
Chris Caudle
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
10:50 p.m.
Anders Hellquist <lau(a)hellquist.net> writes:
I have three Motu devices and Motu have changed their
CC USB stance to
only allow 24 + 24 streams over usb.
This happened a long time ago with a firmware update for Ultralite AVB
which did support 64+64 when running 44k1 or 48k.
Newer models of Ultralite does not support downgrading to older
firmware that supports more than 32 streams.
The same seems be the case with my Motu 24ai and might be true even if
running native driver for Windows or MacOS (have not tried) Motu 24ai
supports 72 channels + avb streams so I'm total. Close to 170 channels
so the limited USB support really cripple the usage.
I have repeatedly been I contact with Motu support and the state they
love Linux and promises things will improve but so far there has been
no proof to back it up.
Motu has not changed the documentation regarding these limits and I
have pointed out the fact that they are advertising stuff that is no
longer true but they promise to fix the documentation but it is all
just talk.
I would say, stay away from Motu if possible.
I don't have any MADI hardware, so I probably shouldn't even be
wondering this, but...is there some kind of problem for the vendor
supporting that much bandwidth over USB, that would make them regret
that they ever promised it?
I have experienced some disappointment with the way everything is headed
to USB, tossing out PCI-E and firewire to get there. It never seemed
like a great idea, especially for those wanting low latency. Is this
what we get now that we've gone down that path?
11:24 p.m.
* Anders Hellquist <lau(a)hellquist.net> [2021-03-12 21:40]:
I have three Motu devices and Motu have changed their
CC USB stance to only
allow 24 + 24 streams over usb.
This happened a long time ago with a firmware update for Ultralite AVB
which did support 64+64 when running 44k1 or 48k.
Newer models of Ultralite does not support downgrading to older firmware
that supports more than 32 streams.
The same seems be the case with my Motu 24ai and might be true even if
running native driver for Windows or MacOS (have not tried) Motu 24ai
supports 72 channels + avb streams so I'm total. Close to 170 channels so
the limited USB support really cripple the usage.
I have repeatedly been I contact with Motu support and the state they love
Linux and promises things will improve but so far there has been no proof
to back it up.
In my perception RME cards were the most decent cards under Linux until
they started their fireface series. Until then pci, pcie, cardbus and
expresscards allowed linux use of everything up to their madiface (yes,
with full 64 I/O). When it became clear that this happy situation is
fading away, especially on laptops without expresscards slots, Motu
seemed like a good alternative for a short time, until these
disadvantages were introduced that Anders and many others mentioned. For
now I feel that the best way is to go for USB class compliant interfaces
that have no on board mixer of FX. Speaking of Madi, this also means
being limited to 24 or 48 channels I/O depending on if it is an RME,
Digico, or Motu device).
I discovered that Adrian Knoth is working on an alsa driver for the
RME MADI FX at https://github.com/adiknoth/madifx
Now what is the current state of AVB interfaces for Linux. Does anyone know how
well this format and its devices are supported in 2021?
cheersz, P
13 Mar
13 Mar
12:04 a.m.
On Fri, 12 Mar 2021 22:25:48 +0100
"Peter P." <peterparker(a)fastmail.com> wrote:
In my perception RME cards were the most decent cards
under Linux until
they started their fireface series. Until then pci, pcie, cardbus and
expresscards allowed linux use of everything up to their madiface (yes,
with full 64 I/O).
** snip **
For now I feel that the best way is to go for USB
class compliant interfaces
that have no on board mixer of FX.
I've been very happy with my RME Babyface Pro in CC mode with Linux.
Maybe I'm missing out not having its onboard FX, but it doesn't feel that
way. I really don't mind not having the TotalMix software. I do everything
I need to either with JACK/Mixbus tools or the onboard mix/routing functions.
It's a level of CC usability I'd love to see in other interface makers.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
10:28 a.m.
* Joe Hartley <jh(a)brainiac.com> [2021-03-12 23:05]:
On Fri, 12 Mar 2021 22:25:48 +0100
"Peter P." <peterparker(a)fastmail.com> wrote:
Of
course! I am currently looking at interfaces with more than 16
channels. Glad to hear it works for you! I am sure there are many
interfaces with about 12 I/O that do work well in CC mode, as for
example the Behringer umc1820.
Peter
In my perception RME cards were the most decent
cards under Linux until
they started their fireface series. Until then pci, pcie, cardbus and
expresscards allowed linux use of everything up to their madiface (yes,
with full 64 I/O).
** snip **
For now I feel that the best way is to go for USB
class compliant interfaces
that have no on board mixer of FX.
I've been very happy with my RME Babyface Pro in CC mode with Linux.
Maybe I'm missing out not having its onboard FX, but it doesn't feel that
way. I really don't mind not having the TotalMix software. I do everything
I need to either with JACK/Mixbus tools or the onboard mix/routing functions.
It's a level of CC usability I'd love to see in other interface makers.
18 Apr
18 Apr
2:21 a.m.
* Peter P. <peterparker(a)fastmail.com> [2021-03-12 18:43]:
Hi list,
can report that the Motu M64 Madi interface does work with a limited
channel count of 24 for input and another 24 for output (instead of 64
each). So if you are coming across a venue or employer that already has
one, you are good to go. Sample rate needs to be set on the device
before starting jack. Of course, buying the card for oneself for so much
money getting only one third of the channels seems useless linux users
IMHO.
I can add now that the card does not work reliably in class compliant
mode with external sync clocks. It will randomly switch back and forth
output channels in banks of eight, cause clicks and distortion and
aliasing artifacts. Note that Motu will not provide you with tech
support unless you register your product and use a special tech support
system, they refuse to provide tech support via email. I am trying to
avoid them as manufacturer in the future wherever I can.
best, Peter
5:43 a.m.
On Sat, Apr 17, 2021 at 4:22 PM Peter P. <peterparker(a)fastmail.com> wrote:
* Peter P. <peterparker(a)fastmail.com>
[2021-03-12 18:43]:
The bank switching is a known problem with other MOTU USB devices, and has
been "solved" by using specific firmware releases (e.g. for the MOTU
Ultralite AVB) which may not be available anymore or for your specific
device.
I do not believe that the aliasing is caused by bank switching, but by
(possibly) an ALSA driver bug. It generally goes away within a few minutes
or on device restart.
Hi list,
can report that the Motu M64 Madi interface does work with a limited
channel count of 24 for input and another 24 for output (instead of 64
each). So if you are coming across a venue or employer that already has
one, you are good to go. Sample rate needs to be set on the device
before starting jack. Of course, buying the card for oneself for so much
money getting only one third of the channels seems useless linux users
IMHO.
I can add now that the card does not work reliably in class compliant
mode with external sync clocks. It will randomly switch back and forth
output channels in banks of eight, cause clicks and distortion and
aliasing artifacts.
11:08 a.m.
* Paul Davis <paul(a)linuxaudiosystems.com> [2021-04-18 03:43]:
On Sat, Apr 17, 2021 at 4:22 PM Peter P.
<peterparker(a)fastmail.com> wrote:
Thanks Paul, that is good to know! Does anyone have more info on this
back switching and associated firmware updates?
* Peter P. <peterparker(a)fastmail.com>
[2021-03-12 18:43]:
The bank switching is a known problem with other MOTU USB devices, and has
been "solved" by using specific firmware releases (e.g. for the MOTU
Ultralite AVB) which may not be available anymore or for your specific
device. Hi list,
can report that the Motu M64 Madi interface does work with a limited
channel count of 24 for input and another 24 for output (instead of 64
each). So if you are coming across a venue or employer that already has
one, you are good to go. Sample rate needs to be set on the device
before starting jack. Of course, buying the card for oneself for so much
money getting only one third of the channels seems useless linux users
IMHO.
I can add now that the card does not work reliably in class compliant
mode with external sync clocks. It will randomly switch back and forth
output channels in banks of eight, cause clicks and distortion and
aliasing artifacts. I do not believe that the aliasing is caused by bank
switching, but by
(possibly) an ALSA driver bug. It generally goes away within a few minutes
or on device restart.
But wouldn't that driver bug affect all class compliant
interfaces then?
cheers, P
19 Apr
19 Apr
9:59 p.m.
On 4/18/21 12:09 AM, Peter P. wrote:
* Paul Davis <paul(a)linuxaudiosystems.com>
[2021-04-18 03:43]:
(the old firmware versions are very old - they used to allow up to 64
channels in class compliant mode - and do not run in the newest hardware
that you can buy today)
There is a VERY long thread about this here:
https://linuxmusicians.com/viewtopic.php?f=6&t=18046&sid=3586a531a2…
A lot of information - I was just looking at new pages at the end since
last time I looked, and there is a way to get a telnet root login into
the boxes, ha ha - running linux internally of course (I expect this
will be gone in the next firmware release :-)
Anyway - not really a resolution to the issue in the thread, but lots of
ideas to try.
I am running a couple of motu interfaces using a patched kernel that
enables the use of the alternate usb (proprietary) endpoints and that
works mostly fine (64 channels over usb with current firmware, 16A & 8M
tested with this). But the patch does not patch over current kernels and
a LOT has changed in the audio usb driver, I still have to figure out
where to do things now. Sigh.
-- Fernando
On Sat, Apr 17, 2021 at 4:22 PM Peter P.
<peterparker(a)fastmail.com> wrote:
Thanks Paul, that is good to know! Does anyone have more info on this
back switching and associated firmware updates? * Peter P. <peterparker(a)fastmail.com>
[2021-03-12 18:43]:
The bank switching is a known problem with other MOTU USB devices, and has
been "solved" by using specific firmware releases (e.g. for the MOTU
Ultralite AVB) which may not be available anymore or for your specific
device. Hi list,
can report that the Motu M64 Madi interface does work with a limited
channel count of 24 for input and another 24 for output (instead of 64
each). So if you are coming across a venue or employer that already has
one, you are good to go. Sample rate needs to be set on the device
before starting jack. Of course, buying the card for oneself for so much
money getting only one third of the channels seems useless linux users
IMHO.
I can add now that the card does not work reliably in class compliant
mode with external sync clocks. It will randomly switch back and forth
output channels in banks of eight, cause clicks and distortion and
aliasing artifacts. I do not
believe that the aliasing is caused by bank switching, but by
(possibly) an ALSA driver bug. It generally goes away within a few minutes
or on device restart.
But wouldn't that driver bug affect all class compliant
interfaces then?
20 Apr
20 Apr
5:50 p.m.
The problems we had with glitching audio and possibly also channel hopping
seems to affect Apple and windows users too to a degree according to
thrrads at motunation.
That means there are likely bugs in the firmware that are causing
this issue and the Linux problem might not even be a Linux issue.
Since there is now a better way to debug this using the newly discovered
root access, there might be workarounds or other nice things in the pipe.
/Anders
On Mon, Apr 19, 2021, 20:00 Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu>
wrote:
On 4/18/21 12:09 AM, Peter P. wrote:
(the old firmware versions are very old - they used to allow up to 64
channels in class compliant mode - and do not run in the newest hardware
that you can buy today)
There is a VERY long thread about this here:
https://linuxmusicians.com/viewtopic.php?f=6&t=18046&sid=3586a531a2…
A lot of information - I was just looking at new pages at the end since
last time I looked, and there is a way to get a telnet root login into
the boxes, ha ha - running linux internally of course (I expect this
will be gone in the next firmware release :-)
Anyway - not really a resolution to the issue in the thread, but lots of
ideas to try.
I am running a couple of motu interfaces using a patched kernel that
enables the use of the alternate usb (proprietary) endpoints and that
works mostly fine (64 channels over usb with current firmware, 16A & 8M
tested with this). But the patch does not patch over current kernels and
a LOT has changed in the audio usb driver, I still have to figure out
where to do things now. Sigh.
-- Fernando
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
* Paul Davis <paul(a)linuxaudiosystems.com>
[2021-04-18 03:43]:
> On Sat, Apr 17, 2021 at 4:22 PM Peter P. <peterparker(a)fastmail.com>
wrote:
>
>> * Peter P. <peterparker(a)fastmail.com> [2021-03-12 18:43]:
>>> Hi list,
>>>
>>> can report that the Motu M64 Madi interface does work with a limited
>>> channel count of 24 for input and another 24 for output (instead of 64
>>> each). So if you are coming across a venue or employer that already
has
>>> one, you are good to go. Sample rate
needs to be set on the device
>>> before starting jack. Of course, buying the card for oneself for so
much
>>> money getting only one third of the
channels seems useless linux users
>>> IMHO.
>>
>> I can add now that the card does not work reliably in class compliant
>> mode with external sync clocks. It will randomly switch back and forth
>> output channels in banks of eight, cause clicks and distortion and
>> aliasing artifacts.
>
> The bank switching is a known problem with other MOTU USB devices, and
has
been
"solved" by using specific firmware releases (e.g. for the MOTU
Ultralite AVB) which may not be available anymore or for your specific
device.
Thanks Paul, that is good to know! Does anyone have more info on this
back switching and associated firmware updates? > I do not believe that the aliasing is caused
by bank switching, but by
> (possibly) an ALSA driver bug. It generally goes away within a few
minutes
or on
device restart.
But wouldn't that driver bug affect all class compliant
interfaces then?
11 Mar
11 Mar
10:04 p.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
Hi list,
I am wondering which MADI audio interfaces are working for Linux.
So far I had success with an RME Madiface via its ExpressCard. Any other
known candidates?
thanks!
P
* Peter P. <peterparker(a)fastmail.com> [2021-03-09 21:10]:
Hi list,
I am wondering if the Motu M64 Madi audio interface is class compliant
or not. The only information I found so far is Paul Davis mentioning it
was not on https://discourse.ardour.org/t/usb2-3-madi-adat/88392/13
Nevertheless I plugged one in today and was able to select it as a
device in qjackctl but did not get jackd to start using it. I had very
little time and forgot to take logs and messages.
thanks for all hints!
P
11:47 p.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
HI Peter, Hi all.
I can recommend *NOT* to get the RME MaDiFAce Pro.
I have yet to try the latest firmware update but up until now,
the class compliant mode only allows 24 channels instead of 136.
On top of it, presets are not stored on the device and require totalmix on
boot.
I have to leave it on always to preserve the settings in class compliant
mode.
Thibaud
Le jeu. 11 mars 2021 à 21:04, Peter P. <peterparker(a)fastmail.com> a écrit :
Hi list,
I am wondering which MADI audio interfaces are working for Linux.
So far I had success with an RME Madiface via its ExpressCard. Any other
known candidates?
thanks!
P
* Peter P. <peterparker(a)fastmail.com> [2021-03-09 21:10]:
Hi list,
I am wondering if the Motu M64 Madi audio interface is class compliant
or not. The only information I found so far is Paul Davis mentioning it
was not on https://discourse.ardour.org/t/usb2-3-madi-adat/88392/13
Nevertheless I plugged one in today and was able to select it as a
device in qjackctl but did not get jackd to start using it. I had very
little time and forgot to take logs and messages.
thanks for all hints!
P
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
12 Mar
12 Mar
12:51 a.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
On 12/3/21 8:47 am, Thibaud Keller wrote:
HI Peter, Hi all.
I can recommend _*NOT*_ to get the RME MaDiFAce Pro.
I have yet to try the latest firmware update but up until now,
the class compliant mode only allows 24 channels instead of 136.
A single MADI link supports 64 channels up to 48kHz. Higher sample rates
than that you only get 28 channels.
Not sure if that's your issue as you probably know that already, but
worth a mention.
1:09 a.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
Thanks Roger for the suggestion,
we are actually running at 48k.
These limitations seem to be built in as you can see on page 88 of the
manual
https://www.rme-audio.de/downloads/mface_pro_e.pdf
Le jeu. 11 mars 2021 à 23:51, Roger <gurusonic(a)gmail.com> a écrit :
On 12/3/21 8:47 am, Thibaud Keller wrote:
HI Peter, Hi all.
I can recommend _*NOT*_ to get the RME MaDiFAce Pro.
I have yet to try the latest firmware update but up until now,
the class compliant mode only allows 24 channels instead of 136.
A single MADI link supports 64 channels up to 48kHz. Higher sample rates
than that you only get 28 channels.
Not sure if that's your issue as you probably know that already, but
worth a mention.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
13 Mar
13 Mar
1 a.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
On 2021-03-12 00:08:53 (+0100), Thibaud Keller wrote:
Thanks Roger for the suggestion,
we are actually running at 48k.
These limitations seem to be built in as you can see on page 88 of the
manual
https://www.rme-audio.de/downloads/mface_pro_e.pdf
This might be due the fact, that the class compliant mode is not aimed
at Linux and/or general computing, but there to support iPads (that's at
least the case in the Fireface UFX series).
I received this fun piece of information from an RME employee at
superbooth two years ago. The channel limitations in class compliant
mode in e.g. the RME Fireface UFX (II, +, etc.) are hardcoded and
matched to the capabilities of some iPad version that was supposed to be
supported back then (and is by now long EOL).
Given, that these devices cost up to several thousands of EUR, this is a
pretty sad state of affairs tbh.
Best,
David
--
https://sleepmap.de
10:30 a.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
* David Runge <dave(a)sleepmap.de> [2021-03-13 00:01]:
On 2021-03-12 00:08:53 (+0100), Thibaud Keller wrote:
Good to learn, thanks David!
I am just wondering if this is the only reason motu and rme and possible
other manufacturers are limiting channels for their interfaces in CC
mode.
cheersz, P
Thanks Roger for the suggestion,
we are actually running at 48k.
These limitations seem to be built in as you can see on page 88 of the
manual
https://www.rme-audio.de/downloads/mface_pro_e.pdf
This might be due the fact, that the class compliant mode is not aimed
at Linux and/or general computing, but there to support iPads (that's at
least the case in the Fireface UFX series).
I received this fun piece of information from an RME employee at
superbooth two years ago. The channel limitations in class compliant
mode in e.g. the RME Fireface UFX (II, +, etc.) are hardcoded and
matched to the capabilities of some iPad version that was supposed to be
supported back then (and is by now long EOL). 
11:52 a.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
On Sat, Mar 13, 2021 at 12:00:39AM +0100, David Runge wrote:
I received this fun piece of information from an RME
employee at
superbooth two years ago. The channel limitations in class compliant
mode in e.g. the RME Fireface UFX (II, +, etc.) are hardcoded and
matched to the capabilities of some iPad version that was supposed to be
supported back then (and is by now long EOL).
I got the same explanation also from an RME salesperson (probably the
same) at the TMT some years ago.
Ciao,
--
FA
15 Mar
15 Mar
6:37 p.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
On 3/12/21 3:00 PM, David Runge wrote:
On 2021-03-12 00:08:53 (+0100), Thibaud Keller wrote:
Ha, interesting... I was actually looking at the usb spec a couple of
days ago (due to this thread) and trying to find a reference to limits
on channel count - a quick browse/search did not find anything but I may
have missed it. Maybe this is in some other document.
Thanks Roger for the suggestion,
we are actually running at 48k.
These limitations seem to be built in as you can see on page 88 of the
manual
https://www.rme-audio.de/downloads/mface_pro_e.pdf
This might be due the fact, that the class compliant mode is not aimed
at Linux and/or general computing, but there to support iPads (that's at
least the case in the Fireface UFX series). I received this fun piece of information from an RME
employee at
superbooth two years ago. The channel limitations in class compliant
mode in e.g. the RME Fireface UFX (II, +, etc.) are hardcoded and
matched to the capabilities of some iPad version that was supposed to be
supported back then (and is by now long EOL).
Motu's original firmware for the AVB interfaces was upgraded early on to
be able to do up to 64 channels on usb2 (which I have been using
extensively). It was latter downgraded to just 24. I started a ticket
and was told that they were having (unspecified) problems with it.
There is a hack that makes it possible to connect the linux usb driver
to the proprietary usb endpoints of the audio interface and thus run at
up to 64 channels (for 44.1/48KHz sampling rate, of course). This
involves kernel patches and also manually switching the interface to the
proprietary mode through an hhtp/json command (otherwise it just uses
the class compliant endpoints[*] after you plug it in). This very long
thread has information about this:
https://linuxmusicians.com/viewtopic.php?f=6&t=18046&sid=3deb30fa5d…
(many options explored but no real solution that works all the time)
While the hack makes it possible to use 64 channels on newer hardware
that cannot be downgraded to the older Motu firmware, its behavior is
not 100% reliable - it might be better behaved in 5.11+ but I have not
tried yet.
-- Fernando
[*] I imagine there is some initial handshake that tells the card that
the motu driver is accessing it, and that is obviously missing in linux
30 Apr
30 Apr
10:37 p.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
On 3/15/21 9:37 AM, Fernando Lopez-Lezcano wrote:
...
Motu's original firmware for the AVB interfaces
was upgraded early on to
be able to do up to 64 channels on usb2 (which I have been using
extensively). It was latter downgraded to just 24. I started a ticket
and was told that they were having (unspecified) problems with it.
There is a hack that makes it possible to connect the linux usb driver
to the proprietary usb endpoints of the audio interface and thus run at
up to 64 channels (for 44.1/48KHz sampling rate, of course). This
involves kernel patches and also manually switching the interface to the
proprietary mode through an hhtp/json command (otherwise it just uses
the class compliant endpoints[*] after you plug it in). This very long
thread has information about this:
https://linuxmusicians.com/viewtopic.php?f=6&t=18046&sid=3deb30fa5d…
< just for the record, latest update >
I am using one of the solutions in that thread successfully (so far :-),
see pages 40/41 for the latest. Running in an 8M with the latest firmware.
"Drumfix"s modified ua101 driver with matched kernel patches and
blacklisting (as outlined in the thread) seems to work just fine in
proprietary mode (64 channels at 48KHz sampling rate). No channel
hopping or buzzing high frequency artifacts.
A caveat: this solution does NOT really work if the kernel is a realtime
preemption kernel (patched with the RT patch and configured with
CONFIG_PREEMPT_RT). Well, it works but the video performance is really
bad in my system, choppy with periodic long lags (~> 0.5 sec) in the
GUI. This is apparently due to the many context switches happening in
the RT kernel because of the high rate of interrupts.
It DOES work fine in a "normal" kernel configured with CONFIG_PREEMPT=y
(what drumfix advised), which is what I am currently using. I can run
jackd at 128x2 which is not bad (with a few xruns if I switch desktops
and all that, otherwise fine).
...
[*] I imagine there is some initial handshake that
tells the card that
the motu driver is accessing it, and that is obviously missing in linux
That is indeed the case. The aforementioned solution still requires a
curl command to switch the motu to proprietary mode, but the recent root
hack has enabled someone to figure out the usb commands used to do that,
so this may be incorporated into the driver in the future.
Best,
-- Fernando
12 Mar
12 Mar
8:56 a.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
Thanks for that Info Thibaud,
I also remember anders.vinjar(a)bek.no telling us here that the Digico UB Madi
works, but don't remember if fully and on all channels(?).
Peter
* Thibaud Keller <tibthejazzdude(a)gmail.com> [2021-03-11 22:47]:
HI Peter, Hi all.
I can recommend *NOT* to get the RME MaDiFAce Pro.
I have yet to try the latest firmware update but up until now,
the class compliant mode only allows 24 channels instead of 136.
On top of it, presets are not stored on the device and require totalmix on
boot.
I have to leave it on always to preserve the settings in class compliant
mode.
Thibaud
Le jeu. 11 mars 2021 à 21:04, Peter P. <peterparker(a)fastmail.com> a écrit :
> Hi list,
>
> I am wondering which MADI audio interfaces are working for Linux.
>
> So far I had success with an RME Madiface via its ExpressCard. Any other
> known candidates?
>
> thanks!
> P
>
> * Peter P. <peterparker(a)fastmail.com> [2021-03-09 21:10]:
> > Hi list,
> >
> > I am wondering if the Motu M64 Madi audio interface is class compliant
> > or not. The only information I found so far is Paul Davis mentioning it
> > was not on https://discourse.ardour.org/t/usb2-3-madi-adat/88392/13
> >
> > Nevertheless I plugged one in today and was able to select it as a
> > device in qjackctl but did not get jackd to start using it. I had very
> > little time and forgot to take logs and messages.
> >
> > thanks for all hints!
> > P
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
>
12:43 a.m.
New subject: Working MADI interfaces for Linux? Was Motu M64 Madi interface (not) class compliant?
On 12/3/21 7:05 am, Peter P. wrote:
Hi list,
I am wondering which MADI audio interfaces are working for Linux.
So far I had success with an RME Madiface via its ExpressCard. Any other
known candidates?
RME MADIface USB would possibly be a better option than the Expresscard
version. Win/Mac drivers are the same so I'm guessing it should work the
same.
If I were regularly doing serious recording I would prefer a desktop
with HDSPe MADI to a laptop.
1377
days inactive
1429
days old
linux-audio-user@lists.linuxaudio.org
24 comments
11 participants
participants (11)
-
Anders Hellquist -
Brent Busby -
Chris Caudle -
David Runge -
Fernando Lopez-Lezcano -
Fons Adriaensen -
Joe Hartley -
Paul Davis -
Peter P. -
Roger -
Thibaud Keller