After booting to the desktop, audio will function for a couple of seconds then halt. Either resetting the MOTU M2 with the power button or resetting via pulseaudio is required for sound to continue working.
Hi! I've got an M4 and this is happening to me too! Also, in certain times after playing audio for a long time it stops playing. Funny thing, I have a pair of Adam F5 monitors, and sometimes the M4 stops playing audio when the monitors get powered up from standby mode, or when I power on them. Also sometimes it happens when USB looks like is being resetted (I have a webcam attached and in dmesg I can see disconnected and connected again, or a message about resetting the device number n using xhci_hcd). Also, I usually can see these kind of messages in dmesg when the M4 stops playing audio: [ 4293.896775] perf: interrupt took too long (2529 > 2500), lowering kernel.perf_event_max_sample_rate to 78900 [ 6249.150883] perf: interrupt took too long (3140 > 3127), lowering kernel.perf_event_max_sample_rate to 63600 [ 6815.427843] kauditd_printk_skb: 231 callbacks suppressed Feel free to reach me if you need any test, debug, etc.
I am using a udev rule to keep the soundcard from entering a low power state, but it does not appear to be helping the main issue. I will test more with the rule removed to see if it is preventing further errors. The rule: $ cat /etc/udev/rules.d/99-audiopower.rules ATTRS{idVendor}=="07fd", ATTRS{idProduct}=="0008", ATTR{power/control}="on", ATTR{power/persist}="0" Which appears to be triggered successfully: https://paste.ee/p/QZVPN Once I restart my card, currently no other circumstances have caused it to enter the halted state. There are no additional dmesg entries either when the sound halts, nor when I reset the device via pulseaudio, causing the audio to function again. Here is a video demonstration of what happens upon each boot: https://youtu.be/7MUWYGhzvPI The upgrade to 5.9.10-arch1-1 does not appear to change behavior.
Exactly the same problem on 5.9.11 on Gentoo.
A bunch of changes for USB-audio implicit feedback will be merged to 5.11 kernel, including the fixes / cleanups for MOTU quirks. At least, MOTU M2 was confirmed to work there. The patches are found in the linux-next tree now or topics/usb-audio-refactoring branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Those are based on 5.10-rc, so you can cleanly merge into the latest 5.10 Linus tree.
Always appreciated Takashi, thank you. I'll test as soon as possible.
Yesterday Arch released 5.9.12-arch1-1 which I am booted into now, the bad behavior doesn't appear to have changed. Please let me know if there is any information I can give you.
As mentioned, the fix are planned to be 5.11 kernel. You'd need to test 5.10-rc kernel with the pull from topic/usb-audio-refactoring branch.
Sigh, I got too excited when I saw the minor number, sorry.
kernel: 5.11.0-rc5-next-20210129-1-next-git With this kernel I was able to boot into a working desktop. While I am experiencing some issues with certain software, I have seen no issues at all with my MOTU M2. I consider this issue solved.
I have this issue. I realised that if I power on the audio interface straight after powering on my laptop it works straight away, otherwise (interface powered on beforehand or after a certain delay) it requires a power cycle to work. However, I have a further issue. The audio output always stops after a while. After this happens pavucontrol still shows audio being outputted but the output meters on the front of the device stop moving and no audio is heard. Power cycling after this happens can help to restore audio output but it eventually cuts out again. I tried 5.11 and beyond on Manjaro and 5.11 on Xubuntu LiveDVD and the issue is always present. Motu M2. I originally commented on https://bugzilla.kernel.org/show_bug.cgi?id=207023 but I think this issue is more directly relevant.
I meant to post this on https://bugzilla.kernel.org/show_bug.cgi?id=211975, sorry.