Bug 211975 - Motu M2 needs a power cycle to work
Summary: Motu M2 needs a power cycle to work
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
Depends on:
Reported: 2021-02-27 09:09 UTC by Hadrien Lacour
Modified: 2023-12-30 18:21 UTC (History)
8 users (show)

See Also:
Kernel Version: 5.11.1
Regression: No
Bisected commit-id:

Test fix (702 bytes, patch)
2021-02-27 17:41 UTC, Takashi Iwai
Details | Diff

Description Hadrien Lacour 2021-02-27 09:09:47 UTC
Hello, after following https://bugzilla.kernel.org/show_bug.cgi?id=210339 and updating to 5.11.1 on Gentoo, my problem still isn't fixed and I noticed the original description didn't really fit my case.

When the card is powered on by the computer (button on ON position during boot), no sound is reaching it after boot, as seen by the integrated meters. After a power cycle and a pause after the first time data is sent to it, I get sound.

dmesg doesn't give any information, as the device is properly detected and Alsa does see the device both before and after; just no sound initially.
Comment 1 Takashi Iwai 2021-02-27 17:40:43 UTC
5.11 got a fix for MOTU and a part of it was the drop of the boot quirk, as it was confirmed to work fine without it.  But it might still needed in some cases (maybe the firmware version?).

Below is a patch to revive the quirk code.  Could you check whether it cures?
Comment 2 Takashi Iwai 2021-02-27 17:41:07 UTC
Created attachment 295511 [details]
Test fix
Comment 3 Hadrien Lacour 2021-02-28 09:25:37 UTC
Hello, it doesn't work (exact same behaviour as before). It's worth mentioning that I did have the same result on 5.10, before upgrading to 5.11.

lsusb -v says this for my card:
Bus 001 Device 005: ID 07fd:0008 Mark of the Unicorn M Series
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x07fd Mark of the Unicorn
  idProduct          0x0008 M Series
  bcdDevice            1.02
  iManufacturer           1 MOTU
  iProduct                3 M2
  iSerial                 2 M20000051722
  bNumConfigurations      1

(ask if you want the whole block, it is quite big)
Comment 4 Hadrien Lacour 2021-03-04 07:34:02 UTC
I must report that it works sometimes. Didn't manage to find any pattern, but I don't have to power cycle it maybe 25% of the time.
Comment 5 Hadrien Lacour 2021-03-13 08:10:38 UTC
Must have been tired when writing the previous comment, but if it _did_ happen, it didn't since; probably never worked.
Comment 6 Daniel Miranda 2021-04-28 13:39:50 UTC
I am still experiencing the issue with the device "hanging" with kernel 5.11.16. It won't happen at boot, but after an indeterminate amount of time; sound output stops, but the device is still powered. A power-cycle gets it back to order. There are no relevant messages in the kernel log.
Comment 7 Hadrien Lacour 2021-05-31 15:38:53 UTC
It recently started to work; am currently on 5.11.22, absolutely nothing else changed.
Comment 8 Hadrien Lacour 2021-07-10 10:21:07 UTC
Stopped working on 5.12. I could try to bisect if this is wanted.
Comment 9 g 2021-09-16 15:07:37 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 10 Alexander Tsoy 2021-09-16 15:31:32 UTC
MOTU increased boot timeout in their Windows driver from 2 seconds to about 3.7 seconds at some point. Could you try to increase it and see if it helps?

Comment 11 Alexander Tsoy 2021-09-16 15:35:31 UTC
I think something like msleep(4000) should make it work reliably.
Comment 12 g 2021-09-27 12:14:28 UTC
(In reply to Alexander Tsoy from comment #10)
> Could you try to increase it and see if it helps?

I don't know how to do that.
Comment 13 Jonathan Hauser 2022-01-04 09:12:18 UTC
I can confirm that msleep(4000) fixes the problem. The audio output keeps working even after several hours of use. Before audio output often already stopped after about 20 minutes.
Comment 14 Marvin Sach 2022-06-12 12:03:23 UTC
For me the need to power-cycle the device persists with kernel 5.18.3 on Manjaro. I tried recompiling the kernel with an increased timeout of 4000 ms or even 8000 ms and could not see an improvement.
Comment 15 Jeremie Knuesel 2023-12-10 20:16:24 UTC
I also confirm that msleep(4000) fixes the problems I have with my Motu M2 first hardware version (firmware 1.02). The device would fail in various ways when trying to use it, the only way to make it work was to turn it on as soon as possible during boot, before the desktop loads then open it directly in jack. With msleep(4000) I can turn it on at any time and use it with any app.
Comment 16 Takashi Iwai 2023-12-11 16:49:37 UTC
OK, that looks like a safe and effective workaround.
Care to send a patch to increase the delay to the upstream?
Comment 17 Jeremie Knuesel 2023-12-13 10:15:12 UTC
Sure, I'll do some more testing (I might get my hands on a Motu M4 of different hardware revision with different firmware) and send a patch if all is well.
Comment 18 Alexander Tsoy 2023-12-13 14:01:47 UTC
(In reply to Jeremie Knuesel from comment #17)
> I might get my hands on a Motu M4 of different hardware revision
> with different firmware
Different revisions have different USB IDs. The quirk will only apply to the first revision which has id 07fd:0008.
Comment 19 Jeremie Knuesel 2023-12-17 11:31:23 UTC
Ah perfect then I'm done with testing. Patch sent here: https://lore.kernel.org/linux-sound/20231217112243.33409-1-knuesel@gmail.com/T/#u
Comment 20 lorentzen.alexander 2023-12-30 13:47:37 UTC
(In reply to Jeremie Knuesel from comment #19)
> Ah perfect then I'm done with testing. Patch sent here:
> https://lore.kernel.org/linux-sound/20231217112243.33409-1-knuesel@gmail.com/
> T/#u

Hello, any news on this with regards to the Motu M4?
I'm running the latest revision M4 (07fd:000b), and I still face these disconnection issues.

I've made a post about it before (https://bugzilla.kernel.org/show_bug.cgi?id=217601), a few months back, but the issue is still not resolved.
Comment 21 Alexander Tsoy 2023-12-30 18:21:44 UTC
(In reply to lorentzen.alexander from comment #20)
> I'm running the latest revision M4 (07fd:000b), and I still face these
> disconnection issues.
Then you have a different issue. The fix only applies to 07fd:0008 and it is already in mainline and queued for the next stable releases.

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