Bug 210339 - MOTU M2 Hangs on boot
Summary: MOTU M2 Hangs on boot
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-23 23:25 UTC by Luke Tidd
Modified: 2021-09-16 15:07 UTC (History)
5 users (show)

See Also:
Kernel Version: 5.9.9-arch1-1
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Luke Tidd 2020-11-23 23:25:39 UTC
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.
Comment 1 Angel 2020-11-24 18:26:08 UTC
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.
Comment 2 Luke Tidd 2020-11-24 21:11:59 UTC
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.
Comment 3 Hadrien Lacour 2020-12-02 16:44:28 UTC
Exactly the same problem on 5.9.11 on Gentoo.
Comment 4 Takashi Iwai 2020-12-02 16:50:02 UTC
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.
Comment 5 Luke Tidd 2020-12-02 17:54:48 UTC
Always appreciated Takashi, thank you.

I'll test as soon as possible.
Comment 6 Luke Tidd 2020-12-07 13:29:56 UTC
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.
Comment 7 Takashi Iwai 2020-12-07 13:32:45 UTC
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.
Comment 8 Luke Tidd 2020-12-07 13:34:46 UTC
Sigh, I got too excited when I saw the minor number, sorry.
Comment 9 Luke Tidd 2021-01-31 16:25:10 UTC
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.
Comment 10 g 2021-09-16 15:03:22 UTC
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.
Comment 11 g 2021-09-16 15:07:12 UTC
I meant to post this on https://bugzilla.kernel.org/show_bug.cgi?id=211975, sorry.

Note You need to log in before you can comment on or make changes to this bug.