Ultralite AVB

[buonamorte.records]

I think you're in the wrong place, probably you've to write to motu support or in a windows forum...

[GraysonPeddie]

Gentlemen,

Has anyone tried writing drivers for MOTU Ultralite-MK5 on Windows 11, but without that bouncing ball, when screen goes to "sleep"

I want black screen, but instead I got eternal bouncing ball.
Can someone help me with that?

That refresh state on display makes my eyes dizzy. It doesn't look good to me.

Are you by any chance a Linux user? This is not a Windows Musician forum.

[mnemonic]

Hi all,

I just stumbled across this thread again, hoping to find a solution to my problems with my MOTU 16A connected via USB in vendor mode to my Manjaro Linux machine, which uses the Drumfix kernel patch and driver.

First of all, thank you very much for the extremely valuable work and this super intressing and helpful thread!

Since my computer's motherboard provides a Thunderbolt 2 header, I was wondering if a PCIe Thunderbolt 2 card would solve the problems.

But according to this comment

1. Would it make a difference if I used thunderbolt on my Linux-laptop instead of the USB port?
   It simply won't work at all. Over thunderbolt the device is like a remote PCIe card that requires a proprietary driver.

there doesn't seem to be any way for the MOTU interface to even be recognized as a sound device over a Thunderbolt connection, not to mention operating as a high performance audio interface. Right?

Can anyone tell me how this works on a Mac? Is there a specific Thunderbolt driver? And if so, does that come from Apple or MOTU? @AudioNarwhal is there any hope that MOTU will provide us with a Thunderbolt 2 driver for Linux? Or that the community can develop such a driver?

Is avb4linux the solution? @Drumfix to what extent is the project "ready to go" for semi-professional use?

Is there any hope to use the full potential of MOTU AVB audio interfaces on Linux soon? Or do I have to switch to Windows or Mac for that?

[buonamorte.records]

For what i've seen, there is no way to solve it. Maybe a new kernel or alsa, but at this time we've lost all our hopes...i'm trying to sell my 4 motu + avb switch...

[j_e_f_f_g]

If the linux support for a thunderbolt 2 device hasn't already been delivered by now, then it's never going to come. Thunderbolt 2 is obsolete. (I think the latest is thunderbolt 4.) I strongly recommend that the OP not sink any money into it.

I owned a MOTU interface. I liked it. But I was using it on Windows. It completely failed to work on linux. MOTU's product line is not linux compatible.

[bluebell]

If the linux support for a thunderbolt 2 device hasn't already been delivered by now, then it's never going to come. Thunderbolt 2 is obsolete. (I think the latest is thunderbolt 4.) I strongly recommend that the OP not sink any money into it.

I owned a MOTU interface. I liked it. But I was using it on Windows. It completely failed to work on linux. MOTU's product line is not linux compatible.

My UltraLite AVB (older version without ESS chips) works perfectly with Drumfix' ua101 driver.

I guess there is a issue in the Linux kernel that fails to handle some USB errors, and as long as you have a good chipset and a fast CPU you won't run into those problems.

[shellwalker]

I guess there is a issue in the Linux kernel that fails to handle some USB errors, and as long as you have a good chipset and a fast CPU you won't run into those problems.

Well, actually my understanding is that the underlying issue is a bug in the implementation inside the MOTU device itself (I believe some FPGA part?), not in the Linux kernel. The issue thus probably also affects MacOs users as well if they are running in class compliant mode (AudioNarwhal has not commented on my inquiry regarding MacOs though).
If I remember it correctly, MOTU no longer has access to the source code for that internal part, such that the recent approach was to try and work around the issue in the accompanying firmware. However the results of this approach are suboptimal because that does cause a break in the audio stream from time to time.
We haven't heard an update from AudioNarwhal (MOTU) since about 4 months now, so it looks like we have been dropped out in the cold
So, personally I'm also giving up the idea of using this device under Linux (vendor mode did not work for me on my 828ES either). I'm rather disappointed and think that MOTU has cheated here, when they claimed audio class compatibility!

[buonamorte.records]

I guess there is a issue in the Linux kernel that fails to handle some USB errors, and as long as you have a good chipset and a fast CPU you won't run into those problems.

Well, actually my understanding is that the underlying issue is a bug in the implementation inside the MOTU device itself (I believe some FPGA part?), not in the Linux kernel. The issue thus probably also affects MacOs users as well if they are running in class compliant mode (AudioNarwhal has not commented on my inquiry regarding MacOs though).
If I remember it correctly, MOTU no longer has access to the source code for that internal part, such that the recent approach was to try and work around the issue in the accompanying firmware. However the results of this approach are suboptimal because that does cause a break in the audio stream from time to time.
We haven't heard an update from AudioNarwhal (MOTU) since about 4 months now, so it looks like we have been dropped out in the cold
So, personally I'm also giving up the idea of using this device under Linux (vendor mode did not work for me on my 828ES either). I'm rather disappointed and think that MOTU has cheated here, when they claimed audio class compatibility!

Do we know who is the owner of the source code for the internal part? I can try to write a mail to the owner...

[buonamorte.records]

Hi Piermarco,

I am doing well, thank you! I hope you are well too. My apologies for not checking in on the LinuxMusicians thread lately as I have been a preoccupied with some other projects. I have spent some time here and there experimenting with writing an ALSA driver, which is starting to show some promise, but is far from being ready to share. There is also the thread of trying to discover other firmware workarounds that I have been struggling to follow up on. Regrettably, because Linux isn't officially supported for these interfaces, and there are a lot of other projects going on at the moment, these tasks frequently fall to the bottom of my list.

I understand that you need to prioritize having a working setup for your studio. So, I am sorry that I wasn't able to get you up and running. Getting this hardware to work well under Linux is something I would personally love to see, but realistically I only have so much time to dedicate to this. It will likely be some time before there are any meaningful developments to share. Thank you for your patience and reaching out in the first place. The discussions here and on LinuxMusicians have helped to shed light on the issues we face with Linux, and help us to design more compatible devices moving forward.

Best,

Dylan

News from Dylan...but: i've made a fresh install of new libretto mxlinux, my ultralite with ess now is working without problems (3 days testing..) at all. I've installed the liquorix kernel. Can someone other test it with the same distro?

[stanlea]

On my side Motu 828 ES, working on class compliant mode, with last firmware from AudioNarwhal, I mean no audio trouble and when channel hoping occurs, just running the small piece of program he posted there, no big deal.

[mnemonic]

Hi all,

I am responding to my own post and sharing my little journey with you.

I just stumbled across this thread again, hoping to find a solution to my problems with my MOTU 16A connected via USB in vendor mode to my Manjaro Linux machine, which uses the @Drumfix kernel patch and driver.

Just for the record: I got it to work - with some limitations!

I had really big problems getting my 16A to work in vendor mode under Linux with custom kernel, the Drumfix driver and patch using Ardour and ALSA. I had all the problems described in this thread and even more. It just wasn't usable for me at all.

But the experimental firmware from @AudioNarwhal gave some hope - channel hopping and crackling occurred less, and when they did, the sync utility fixed the problem - mostly.

But a few weeks ago it started to get worse again. Sometimes I couldn't get it up and running again at all, only the next day everything did run normally as expected.

I wondered what was causing this and found that the 16A unit had become extremely hot in its place in the rack. It was very hot days and nights and my studio was around 30 degrees Celsius. The MOTU was really getting hot! And the problems seemed to increase dramatically.

So I decided to give more space between the units in the rack and install a fan for better air circulation.

And guess what? The situation improved dramatically - the cooler unit definitely runs more stable.

I also decided to try the usb class compliant mode, even though I want to use the maximum number of channels, but now I have to sum it to 24 with the mixer.

This improved the situation even more. I had really started to get hopeful about using Ardour on Linux as my main DAW. But there were still occasional problems with inputs going completely silent, and even the sync-utility couldn't help because it simply couldn't detect an active USB audio stream. But restarting ALSA helped.

Unfortunately, Ardour degraded as the number of tracks increased, so I went nuts again. At least a strange hiss appeared on some input channels, and since I couldn't see any level in the MOTU mixer, I wanted to know if it appears in another DAW too.

Hence I started up Reaper and since then everything has changed completely - even Reaper's user interface is a bit different, it just works. I still can't believe it. Really.

Okay, from time to time my input channels still go silent, but restarting ALSA from within Reaper fixes the problem immediately. So I think there might be a problem with ALSA itself? At least it seems to be volatile somehow.

Maybe one day or another I will try out the vendor mode again. But for now, I'm as happy as I can be!

Thank you all again for your help, effort, time and research. It is truly inspiring to me to see how this community has not given up for such a long time. Kudos!

[buonamorte.records]

Also my 828es seems to work better on reaper...today i'll try with the ultralite

[bluebell]

I have the older version of the UltraLite AVB, without ESS chips.

For over a year I use @Drumfix' ua101 replacement driver with kernel 5.8.6 without any problem. No channel hopping, no distortion.

Yesterday I built kernel 5.15.134. That was the latest v5 kernel I could get. I didn't try a v6 kernel because I read that the developers created a dependency to rust and want to enforce a very recent rust (not older than a year). So I won't be able to build a recent kernel on a not so recent system. Anyway.

I tried the dkms driver, see https://github.com/Drumfix/motu-avb-usb
It built and installed without problems but from time to time (especially after reboot) I had the well-kown channel hopping, e.g. computer's outputs 1+2 went to the interface's outputs 9+10.

Then I removed the dkms driver and compiled the ua101 replacement. Had to comment out the line with MODULE_SUPPORTED_DEVICE. First tests are promising. The ua101 driver seems to be as stable under 5.15.134 as under 5.8.6.

[buonamorte.records]

Then I removed the dkms driver and compiled the ua101 replacement. Had to comment out the line with MODULE_SUPPORTED_DEVICE. First tests are promising. The ua101 driver seems to be as stable under 5.15.134 as under 5.8.6.

This is the best way also for ess version. Have you tried with the Dylan's kernel module? This way works, not perfectly but works.. I hope @AudioNarwhal can improve this, when he have time to...it's not easy for us (compile a kernel, comment out a line, not easy way to change samplerate) but, if it's the only way...

[bluebell]

Since I am completely happy with @Drumfix's ua101-replacement I didn't try other solutions (except for his dkms driver which isn't that stable as the ua101-replacement).