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.
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?
Created attachment 295511 [details] Test fix
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)
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.
Must have been tired when writing the previous comment, but if it _did_ happen, it didn't since; probably never worked.
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.
It recently started to work; am currently on 5.11.22, absolutely nothing else changed.
Stopped working on 5.12. I could try to bisect if this is wanted.
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.
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? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/usb/quirks.c?h=v5.15-rc1#n1128
I think something like msleep(4000) should make it work reliably.
(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.
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.
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.
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.
OK, that looks like a safe and effective workaround. Care to send a patch to increase the delay to the upstream?
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.
(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.
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
(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.
(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.