Update on upstream fixes

[ilian]

Here are some updates I found while browsing the upstream repos:

• MOTU M2 config was added to ALSA v1.2.8
• The kernel bug introduced by 5.19.9 was fixed in version 5.19.12.

Could you confirm if using the updated ALSA packages and kernel version no longer require patches or downgrades?
It could be useful to update the README with the current state of the fixes of the upstream repos.

[kiosion]

Those are great to hear! I figured the 5.19 kernel bug was fixed since I was able to upgrade without issues a few weeks back. I can definitely do some more messing around this weekend and see if any of the patches mentioned in the readme are still needed 😄

[XanderBaatz]

Any news on this?

Info:

• I am on a fully updated Fedora 37 (as of 2022-01-07).
• I've got a Motu M4 (2021 rev.).
• I bought the interface summer 2022.
• The firmware has not been updated.
• I am on kernel 6.0.16.

Things I tried:

• I downgraded alsa-ucm to v. 1.2.7.1-1.
• Doing this automatically downgraded alsa-utils to v. 1.2.7-2.
• I used Fedora's package manager (DNF) to lock/hold the version of alsa-ucm package, using the versionlock plugin.

The Pro Audio and Analog Surround 4.0 Output + Analog Surround 4.0 Input profiles are now available for the M4 in pavucontrol under configuration.

However, upon a shutdown of my computer I still have to turn off/on the interface physically for it to work.
I'm using GNOME 43.2, and in audio settings it either says Dummy Output/Input or just completely greyed out.
Applications that are trying to utilize the audio server in this state may crash (such as Firefox, e.g. when playing a YouTube video).
When in this state only the Off profile is available for the M4 in pavucontrol under the Configuration tab.
Above mentioned state happens after a computer boot-up before having turned off and on the M4 USB Interface. During this state the interface appears fully working when looking at the meters.
I've tried connecting the M4 to another computer with different specs. The problem/issue is reproducible, so my primary computer is not the culprit. My previous interface (Audient iD4 MK1) did not face any of these issues.
In the past the audio interface would stop working at random times, usually as a result of changes in the audio server while doing tasks such as gaming and audio editing.

[kiosion]

Same here, forgot to reply but I did try with the latest kernel and updated alsa-* packages, and while it seems to work for the most part now, there's still some occasional weirdness... I can try increasing msleep again, since last time I tried, that seemed to fix the (what I assume are) USB time-out issues...

I'm running an M2 instead of M4, bought it back in ~Sep 2021.

[XanderBaatz]

@kiosion Have you tried updating the firmware? I have not, and I didn't intend to since I don't want to lay hands on Windows to be able install it. But I may want to give it a go.

In regards to the msleep patch, do I need to compile the kernel myself? (I'm a complete beginner when it comes to kernel compilation)

Edit: I succesfully updated the firmware through VirtualBox using USB passthrough.

Edit 2: It appears nothing has changed. The firmware is updated, however upon rebooting my computer I still had to power-cycle the interface to make it work, and for it to appear in Linux.

[kiosion]

I haven't tried that either, and probably won't for the same reason... also in case that makes anything worse since at this point the occasional issues are really more of an annoyance.

And yeah, to change that you need to compile the kernel yourself along with a patch. Not too tricky but kind of a chore to do

[XanderBaatz]

@kiosion When crashes/hiccups happen on your end, do you also encounter your programs freezing/becoming unresponsive until you power-cycle the interface?
I was working in Audacity a few minutes ago, and it stopped working. Audacity froze/became unresponsive. I went to GNOME settings to check audio input/output and both of them were greyed out with no names - like it used to do.
I power-cycled the M4 (physically turn off and then back on), and the program became responsive again.

It's quite infuriating when it happens, especially when in a call on Discord or Matrix, while simultaneously playing a game.

I'll see if I can provide an alsa and pipewire output next time it happens. Maybe we can figure something out. I don't know.

[XanderBaatz]

I thought I might note something.
When I updated the firmware I also installed the Windows driver in the Windows 11 VM. If you don't know the driver software allows you to change sample-rate and buffer size.
The defaults (first time launch) were:

• Sample-rate: 48000 Hz
• Buffer size: 256 samples

Since then I've changed PipeWire's settings to adhere to said 'defaults'.
In my short time of testing yesterday I didn't experience any application hangs. I'll update you down the line.

Edit: Cut outs are more infrequent (seemingly). I was also able to boot the computer once, where the audio interface worked without power-cycling. It's possible that the stability is slightly improved by locking in the sample rate and buffer size.

[kiosion]

@kiosion When crashes/hiccups happen on your end, do you also encounter your programs freezing/becoming unresponsive until you power-cycle the interface? I was working in Audacity a few minutes ago, and it stopped working. Audacity froze/became unresponsive. I went to GNOME settings to check audio input/output and both of them were greyed out with no names - like it used to do. I power-cycled the M4 (physically turn off and then back on), and the program became responsive again.

Yes, but it seems to only be certain programs, which makes me think most are designed to be able to handle unresponsive audio sinks... Discord and Spotify crash along with the interface, but other programs I use seem fine

My PipeWire config is also set to those, maybe that's why I've been experiencing freezes less frequently recently... interesting 🤔

[XanderBaatz]

Hi @kiosion , a little update.
Sorry for breaking up this thread again, but I've got to share this.
I am now on Ubuntu LTS 22.04.2. I've been on this distro for a month now. In the beginning I still had the same problems as I faced on Fedora, concerning the Motu M4.

Last week I made a few changes, and it has not failed on me once ever since. It has worked over multiple boots now, without having to power cycle the interface physically. It does not stop working at random times anymore, it simply "just works". I've been in and out of audio applications like Ardour, Audacity, Carla, EasyEffects and so on, and it has not failed on me once.

What I've done to get here is:

• Install linux-oem-22.04c (6.1.0 kernel as of writing this).
• Add a .conf file to /usr/share/pipewire/pipewire.conf.d/ that holds the code below.
• M4 audio/sound profile set to Analog Surround 4.0 Output + Analog Surround 4.0 Input in PulseAudio Volume Control.

File 50-pipewire-latency.conf in /usr/share/pipewire/pipewire.conf.d/:

context.properties = {
    default.clock.rate          = 48000
    default.clock.allowed-rates = [ 48000 ]
    default.clock.quantum       = 256
    clock.force-quantum         = 256
    #default.clock.min-quantum   = 16
    default.clock.max-quantum   = 256
    #default.clock.quantum-limit = 8192
}

The ridiculous amount of xruns are also completely gone. I hope this may help you or anyone else looking to fix this.

[kiosion]

Thanks for the update! I haven't had nearly as many issues as of late; I haven't had time to track down which change actually fixed it for me but I'll try adding that conf in as well, since I've still had occasional issues with latency

[XanderBaatz]

A little update.

I went back to Fedora as I couldn't live without it. It's just better than Ubuntu in my opinion. I use the default kernel on Fedora and the problems have come back. I still use the config I provided in my previous message, as that seems to help stability when the interface is working. However, upon boot-ups, I still have to power-cycle the interface.
Ubuntu must've had some quirks/fixes in place for this interface. It's a shame really.

Have you made any special tweaks/changes to unburden yourself of this issue?

[kiosion]

Super late reply; I've been quite busy lately... but besides using the modified alsa config files in this repo, this issue seems (knock on wood) to be fixed on the latest Arch kernel / latest alsa version. I'm not getting any of the crackling/audio dropout issues I ran into initially, even leaving the interface on for extended periods without power-cycling. I can test later this week on a more barebones install to see if there's anything else I've changed and forgotten about.

[XanderBaatz]

Hello, I reported it as a bug on Bugzilla a short while ago: https://bugzilla.kernel.org/show_bug.cgi?id=217601

We didn't reach a conclusion, but Jaroslav Kysela proposed a change:

echo "options snd-usb-audio quirk_flags=0x800" > /etc/modprobe.d/alsa.conf

which definitely helped. Now it's ever so slightly more uncommon for it to not work. I switched back to my old interface in the meantime, but I still want to find a permanent fix for the M4. I believe some Steinberg interfaces are also affected, but what I find odd is that it doesn't happen for every M4 owner (seemingly).

[XanderBaatz]

Hi @kiosion .
We've finally tracked down the issue. It may already get patched in kernel 6.8.
This'll apply to M2/M4/M6, as they share the same firmware courtesy of Alexander Tsoy.

If you're interested in how it was solved head here.

Tl;dr, simply apply the quirks:

echo "options snd-usb-audio quirk_flags=0x220" > /etc/modprobe.d/alsa.conf

• 0x200: Adds a 1-2 ms delay between control messages.
  • This helps mitigate the "cannot set freq ..." error.
• 0x20: Applies the skip clock selector quirk.
  • Fixes the interface during boot so it actually works and doesn't crash applications etc., meaning one doesn't have to powercycle the interface for it to work.

Both quirks are applied by summing them to 0x220.