Created attachment 304482 [details] dmesg output log. USB audio interface, DAC: Mark of the Unicorn M4 (MOTU M4) Distribution: Fedora Linux 38 (Workstation Edition) Kernel version: 6.3.8-200.fc38 After booting up my computer, sound/audio is not available. All (most) applications dependent on audio will either not open or simply crash at random (e.g. Firefox, Ardour, Audacity). This is until the MOTU M4 is turned off, physically, then all the apps will start to work as expected. What I've tried so far (to confirm this is not my install/PC acting up): - Using my old USB audio interface (Audient iD4), which works without any problems. - Using other systems, a laptop and a desktop, both running Fedora (36 or 37). MOTU M4 would still not function properly, and would display the exact same behavior. - Using another USB cable (e.g. USB-C to USB-C and USB-C to USB-A), using other USB ports (both 3.x and 2.0). - Switching from wireplumber to pipewire-media-session, changes nothing. - Following the advice on https://github.com/kiosion/alsa-motu-m2 , I've tried to downgrade kernel and alsa packages to no avail, and recently I've also tried to re-compile the kernel with increased msleep (4000ms and 6000ms, respectively). - Blacklisting HDMI audio. - Adding my user to the audio group. Doesn't fix the issue. - Locking the sample-rate and buffer size (among other things) through wireplumber's and PipeWire's configs. No difference. - Using boot quirks (implicit feedback) for snd-usb-audio under /etc/modprobe.d/. Still no difference. - Changing USB-related settings i BIOS/UEFI, like Legacy USB Support and XHCI Hand-Off, as well as PCIe Gen speeds/versions. - Updating the firmware using MOTU's official firmware updater on a Windows machine. Still did not change anything. Currently on the latest available firmware (March 29th). Looking at different logs, what stood out to me was: - dmesg: parse_audio_format_rates_v2v3(): unable to find clock source (clock -110) - spa-acp-tool: Error opening PCM device _ucm0001.hw:M4: Device or resource busy - spa-acp-tool: snd_pcm_hw_params_any() failed: Invalid argument To get the audio working, I have to power cycle the interface physically. This has always been the case with the MOTU M4, however I once tried out Ubuntu LTS 22.04 with the latest OEM kernel. There the interface seemed to work the majority of the time, even on boot-ups. I've tried Manjaro, PopOS, Nobara, KDE Neon. It happens on all of them. I've also tried older kernel versions, older versions of ALSA-related packages and nothing appears to change/fix it. I believe this is something kernel-related.
Can you compile and test v5.15 kernel on your Fedora system (see Documentation/admin-guide/quickly-build-trimmed-linux.rst)? If it works, can you bisect this regression to find culprit commit (see Documentation/admin-guide/bug-bisect.rst)?
(In reply to Bagas Sanjaya from comment #1) > Can you compile and test v5.15 kernel on your Fedora system (see > Documentation/admin-guide/quickly-build-trimmed-linux.rst)? If it works, can > you bisect this regression to find culprit commit (see > Documentation/admin-guide/bug-bisect.rst)? Hi, I'm new to kernel compilation and the likes. Is it important that I compile it myself (I assume to compare and bisect)? Is there a specific sub-version of 5.15 that you want me to try? In the meantime I've installed kernel 5.15.18 from Fedora 34 (this one specifically: https://koji.fedoraproject.org/koji/buildinfo?buildID=1909969). The audio interface still does not work as expected. From `sudo dmesg`: [ 9.281602] usb 1-1: parse_audio_format_rates_v2v3(): unable to find clock source (clock -110) [ 24.727086] usb 1-1: parse_audio_format_rates_v2v3(): unable to find clock source (clock -110) `uname -r` for reference: [xba@fedora ~]$ uname -r 5.15.18-100.fc34.x86_64
Could you attach output from `lsusb -d 07fd:000b -v` ?
Created attachment 304488 [details] lsusb output.
(In reply to Jaroslav Kysela from comment #3) > Could you attach output from `lsusb -d 07fd:000b -v` ? Attached now.
Could you test this settings ? echo "options snd-usb-audio quirk_flags=0x800" > /etc/modprobe.d/alsa.conf Note that this settings assumes that only one USB card (M4) is present in the system.
(In reply to Jaroslav Kysela from comment #6) > Could you test this settings ? > > echo "options snd-usb-audio quirk_flags=0x800" > /etc/modprobe.d/alsa.conf > > Note that this settings assumes that only one USB card (M4) is present in > the system. Still not working with quirk flags applied. I tried kernel 6.3.9 and 5.15.18 respectively. `sudo dmesg` output: [ 9.283558] usb 1-1: parse_audio_format_rates_v2v3(): unable to find clock source (clock -110) [ 25.172184] usb 1-1: parse_audio_format_rates_v2v3(): unable to find clock source (clock -110) `spa-acp-tool -vvvv lv -c 0` output: Trying _ucm0001.hw:M4 with SND_PCM_NO_AUTO_FORMAT ... ALSA device open '_ucm0001.hw:M4' playback: 0x55ecd271d6f0 snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd271d6f0 Trying _ucm0001.hw:M4 without SND_PCM_NO_AUTO_FORMAT ... ALSA device open '_ucm0001.hw:M4' playback: 0x55ecd271a180 snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd271a180 Trying plug:SLAVE='_ucm0001.hw:M4' with SND_PCM_NO_AUTO_FORMAT ... Unknown PCM _ucm0001.hw:M4 Error opening PCM device plug:SLAVE='_ucm0001.hw:M4': No such file or directory Set ucm verb to HiFi Trying _ucm0001.m4_stereo_out:M4,0,2,3 with SND_PCM_NO_AUTO_FORMAT ... snd_pcm_hw_params_any failed unable to initialize slave Error opening PCM device _ucm0001.m4_stereo_out:M4,0,2,3: Invalid argument Trying hw:0,0 with SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'hw:0,0' playback: 0x55ecd271dd50 snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd271dd50 Trying hw:0,0 without SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'hw:0,0' playback: 0x55ecd27298c0 snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd27298c0 Trying plug:SLAVE='hw:0,0' with SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'plug:SLAVE='hw:0,0'' playback: 0x55ecd270f620 Slave PCM not usable snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd270f620 Trying plug:SLAVE='hw:0,0' without SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'plug:SLAVE='hw:0,0'' playback: 0x55ecd270dc20 Slave PCM not usable snd_pcm_hw_params_any() failed: Invalid argument Failed to set hardware parameters on plug:SLAVE='hw:0,0': Invalid argument ALSA device close 0x55ecd270dc20 Trying hw:0,0 with SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'hw:0,0' capture: 0x55ecd27294a0 snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd27294a0 Trying hw:0,0 without SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'hw:0,0' capture: 0x55ecd27294a0 snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd27294a0 Trying plug:SLAVE='hw:0,0' with SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'plug:SLAVE='hw:0,0'' capture: 0x55ecd270dc20 Slave PCM not usable snd_pcm_hw_params_any() failed: Invalid argument ALSA device close 0x55ecd270dc20 Trying plug:SLAVE='hw:0,0' without SND_PCM_NO_AUTO_FORMAT ... ALSA device open 'plug:SLAVE='hw:0,0'' capture: 0x55ecd270dc20 Slave PCM not usable snd_pcm_hw_params_any() failed: Invalid argument Failed to set hardware parameters on plug:SLAVE='hw:0,0': Invalid argument ALSA device close 0x55ecd270dc20 Found 0 jacks.
Created attachment 304492 [details] alsa-info.sh output in non-working state.
Created attachment 304493 [details] alsa-info.sh output in working state.
I've attached the output-file of the following command: alsa-info.sh --no-upload --with-alsactl --with-aplay --output <output name>.txt In both the non-working and working state. To get to the working state, I power-cycled the interface using the on/off button on the back.
I have 100% success with the mentioned quirk with the 6.3.8 Fedora kernel for the cold boot, but I have probably older firmware installed: - bcdDevice 2.04 + bcdDevice 2.00 It's a weird issue probably caused by a firmware problem. It is difficult to find a workaround (a quirk) for this. I see "parse_audio_format_rates_v2v3(): unable to find clock source (clock -110)" messages only rarely.
(In reply to Jaroslav Kysela from comment #11) > I have 100% success with the mentioned quirk with the 6.3.8 Fedora kernel > for the cold boot, but I have probably older firmware installed: > > - bcdDevice 2.04 > + bcdDevice 2.00 > > It's a weird issue probably caused by a firmware problem. It is difficult to > find a workaround (a quirk) for this. > > I see "parse_audio_format_rates_v2v3(): unable to find clock source (clock > -110)" messages only rarely. Well well, I did a fresh reinstall of Fedora. I tried again with the regular USB 3.x port and cable. Still didn't work. Switched to USB-C to USB-C cable, and it appears to be working now. Cold boots and reboots. FYI I believe I have thunderbolt support disabled in BIOS. Don't know if it changes anything. I'm going to experiment with it a little, to see if it persists. To be clear, the proposed boot quirk is the only thing I applied after reinstalling and updating Fedora 38. As proposed by Kysela: echo "options snd-usb-audio quirk_flags=0x800" > /etc/modprobe.d/alsa.conf
Sadly it started happening again. I can only make it work sometimes. That quirk flag definitely helped a bit, but it still happens very often (on the majority of boot-ups). Oddly enough, `sudo dmesg` stopped saying "parse_audio_format_rates_v2v3(): unable to find clock source (clock -110)" a few times. However `journalctl -b --no-pager | grep wireplumber` outputs: Jun 28 15:10:55 fedora wireplumber[1275]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed? Jun 28 15:10:55 fedora wireplumber[1275]: PipeWire's libcamera SPA missing or broken. libcamera not supported. Jun 28 15:10:56 fedora wireplumber[1275]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NameHasNoOwner Jun 28 15:11:01 fedora wireplumber[1894]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed? Jun 28 15:11:01 fedora wireplumber[1894]: PipeWire's libcamera SPA missing or broken. libcamera not supported. Jun 28 15:11:01 fedora wireplumber[1894]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NameHasNoOwner Jun 28 15:11:06 fedora wireplumber[1275]: can't open control for card hw:0: Permission denied Jun 28 15:11:06 fedora wireplumber[1275]: Error opening hctl device: No such device Jun 28 15:11:06 fedora wireplumber[1275]: Failed to find a working mixer device (_ucm0003.hw:M4). Jun 28 15:11:06 fedora wireplumber[1275]: Error opening hctl device: No such device Jun 28 15:11:06 fedora wireplumber[1275]: Failed to find a working mixer device (_ucm0003.hw:M4). Jun 28 15:11:06 fedora wireplumber[1275]: Error opening hctl device: Permission denied Jun 28 15:11:06 fedora wireplumber[1275]: Error opening hctl device: Permission denied Running `spa-acp-tool -vvvv lv -c 0` indicates that it's still running in loops trying to find/assign profiles. As it did previously. It seems that moving to a USB-C to USB-C cable through the Thunderbolt USB-C port (possibly) helps to eliminate the "parse_audio_format_rates_v2v3(): unable to find clock source (clock -110)" output. I checked my BIOS settings and Thunderbolt support was enabled (I don't know if that affects the port's capabilities in terms of powering USB audio interfaces etc.). So, conclusion: it works some of the time.
Another thing to try: pass the following quirk_alias parameter to the kernel: quirk_alias=07fd000b:07fd0008 This will make the boot delay needed for the 1st revision of M2/M4 applied to your device.
(In reply to Alexander Tsoy from comment #14) > Another thing to try: pass the following quirk_alias parameter to the kernel: > quirk_alias=07fd000b:07fd0008 Ah, no, it is a module parameter. echo "options snd-usb-audio quirk_alias=07fd000b:07fd0008" > /etc/modprobe.d/alsa.conf
Created attachment 305684 [details] skip_clock_selector_set.patch Regarding "parse_audio_format_rates_v2v3(): unable to find clock source (clock -110)" error, can someone test attached patch?
On my machine if MOTU M4(second revision) is plugged in it would boot as normal but my desktop will freeze. power cycling the the m4 fixes it and I can see this log. [ 1.863925] usb 1-6: new high-speed USB device number 4 using xhci_hcd [ 2.004943] usb 1-6: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 [ 2.004955] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.004961] usb 1-6: Product: M4 [ 2.004965] usb 1-6: Manufacturer: MOTU [ 2.004969] usb 1-6: SerialNumber: M4AE0C9064 [ 3.418238] cdc_acm 1-6:1.5: ttyACM0: USB ACM device [ 3.556955] usb 1-6: Quirk or no altest; falling back to MIDI 1.0 [ 13.430705] usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110 [ 19.571750] usb 1-6: USB disconnect, device number 4 [ 19.571783] usb 1-6: uac_clock_source_is_valid(): cannot get clock validity for id 2 [ 19.571785] usb 1-6: clock source 2 is not valid, cannot use [ 21.443946] usb 1-6: new high-speed USB device number 7 using xhci_hcd [ 21.584764] usb 1-6: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 [ 21.584766] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 21.584767] usb 1-6: Product: M4 [ 21.584768] usb 1-6: Manufacturer: MOTU [ 21.584769] usb 1-6: SerialNumber: M4AE0C9064 [ 21.591991] usb 1-6: Quirk or no altest; falling back to MIDI 1.0 [ 21.593074] cdc_acm 1-6:1.5: ttyACM0: USB ACM device First it throws "usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110" error. And when I power off the interface it prints the "usb 1-6: uac_clock_source_is_valid(): cannot get clock validity for id 2" error. (In reply to Alexander Tsoy from comment #15) > (In reply to Alexander Tsoy from comment #14) > > Another thing to try: pass the following quirk_alias parameter to the > kernel: > > quirk_alias=07fd000b:07fd0008 > Ah, no, it is a module parameter. > echo "options snd-usb-audio quirk_alias=07fd000b:07fd0008" > > /etc/modprobe.d/alsa.conf I can confirm that setting the same boot quirk on MOTU M4 second revision(firmware 2.04) fixes the boot issue. I've been running it for the last few days and I can consistently reproduce it by removing the quirk and adding it back. So Do you think it should be patched to get applied for second revision as well?
(In reply to Alexander Tsoy from comment #16) > Created attachment 305684 [details] > skip_clock_selector_set.patch > > Regarding "parse_audio_format_rates_v2v3(): unable to find clock source > (clock -110)" error, can someone test attached patch? Do you know how we can reproduce this issue? It only happened to me twice. I can try running the patch but not being to able to reproduce the problem makes it really hard to verify.
(In reply to mksafavi from comment #17) > [ 13.430705] usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110 Does this error disappear if you also apply SKIP_CLOCK_SELECTOR quirk? echo "options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20" > /etc/modprobe.d/alsa.conf
(In reply to Alexander Tsoy from comment #19) > (In reply to mksafavi from comment #17) > > [ 13.430705] usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110 > Does this error disappear if you also apply SKIP_CLOCK_SELECTOR quirk? > > echo "options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20" > > /etc/modprobe.d/alsa.conf Should applying the SKIP_CLOCK_SELECTOR quirk fix the "cannot get clock validity for id 2" error or the "cannot set freq 44100 (v2/v3): err -110" error? because for me "cannot set freq 44100 (v2/v3): err -110" error disappears by just applying the "quirk_alias=07fd000b:07fd0008" which if I'm not mistaken raises the sleep to 4seconds during boot. right? When I boot it with no quirks applied, I get the "cannot set freq 44100 (v2/v3): err -110" error which you can see it in my log at 13.430705. Then I powered off the interface at 19.571750. It unfroze my desktop and printed the "uac_clock_source_is_valid(): cannot get clock validity for id 2" at 19.571783. Outside of boot time during normal use, sometimes I get the "uac_clock_source_is_valid(): cannot get clock validity for id 2" error. for example I paused a video in my browser. then started playing it again it froze. power cycling the interface printed this error. I'm going to try the SKIP_CLOCK_SELECTOR to see if changes its behavior.
(In reply to Alexander Tsoy from comment #19) > (In reply to mksafavi from comment #17) > > [ 13.430705] usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110 > Does this error disappear if you also apply SKIP_CLOCK_SELECTOR quirk? > > echo "options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20" > > /etc/modprobe.d/alsa.conf Applying the SKIP_CLOCK_SELECTOR quirk brings the "usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110" error back. here's the log: [ 1.827253] usb 1-6: new high-speed USB device number 4 using xhci_hcd [ 1.968313] usb 1-6: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 [ 1.968326] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1.968331] usb 1-6: Product: M4 [ 1.968335] usb 1-6: Manufacturer: MOTU [ 1.968339] usb 1-6: SerialNumber: M4AE0C9064 [ 3.316184] cdc_acm 1-6:1.5: ttyACM0: USB ACM device [ 3.412749] usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 [ 7.467018] usb 1-6: Quirk or no altest; falling back to MIDI 1.0 [ 7.468123] usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 [ 16.420725] usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110 [ 21.943734] usb 1-6: USB disconnect, device number 4 [ 21.943808] usb 1-6: uac_clock_source_is_valid(): cannot get clock validity for id 2 [ 21.943811] usb 1-6: clock source 2 is not valid, cannot use [ 31.934093] usb 1-6: new high-speed USB device number 7 using xhci_hcd [ 32.074781] usb 1-6: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 [ 32.074785] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 32.074786] usb 1-6: Product: M4 [ 32.074787] usb 1-6: Manufacturer: MOTU [ 32.074787] usb 1-6: SerialNumber: M4AE0C9064 [ 32.077230] usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 Also I'm filtering the log by the usb device id "1-6". If the full boot log is necessary let me know. Thanks
(In reply to mksafavi from comment #20) > Should applying the SKIP_CLOCK_SELECTOR quirk fix the "cannot get clock > validity for id 2" error or the "cannot set freq 44100 (v2/v3): err -110" > error? > > because for me "cannot set freq 44100 (v2/v3): err -110" error disappears by > just applying the "quirk_alias=07fd000b:07fd0008" which if I'm not mistaken > raises the sleep to 4seconds during boot. right? Right. But I didn't expect that just applying boot delay quirk would also fix "cannot set freq ..." error.
(In reply to mksafavi from comment #21) > Applying the SKIP_CLOCK_SELECTOR quirk brings the "usb 1-6: 2:1: cannot set > freq 44100 (v2/v3): err -110" error back. Could you also try quirk_flags=0x800 as suggested by Jaroslav combined with quirk_alias=07fd000b:07fd0008 ?
(In reply to Alexander Tsoy from comment #23) > (In reply to mksafavi from comment #21) > > Applying the SKIP_CLOCK_SELECTOR quirk brings the "usb 1-6: 2:1: cannot set > > freq 44100 (v2/v3): err -110" error back. > Could you also try quirk_flags=0x800 as suggested by Jaroslav combined with > quirk_alias=07fd000b:07fd0008 ? I set /etc/modprobe.d/alsa.conf to this: options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x800 It boots just fine. I don't get the "usb 1-6: 2:1: cannot set freq 44100 (v2/v3): err -110" error. Should it also affect the "cannot get clock validity" error? I'm going to keep it running to see if I notice anything. here's the log: [Fri Jan 12 19:05:27 2024] usb 1-6: new high-speed USB device number 4 using xhci_hcd [Fri Jan 12 19:05:27 2024] usb 1-6: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 [Fri Jan 12 19:05:27 2024] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Fri Jan 12 19:05:27 2024] usb 1-6: Product: M4 [Fri Jan 12 19:05:27 2024] usb 1-6: Manufacturer: MOTU [Fri Jan 12 19:05:27 2024] usb 1-6: SerialNumber: M4AE0C9064 [Fri Jan 12 19:05:28 2024] cdc_acm 1-6:1.5: ttyACM0: USB ACM device [Fri Jan 12 19:05:28 2024] usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 [Fri Jan 12 19:05:32 2024] usb 1-6: Quirk or no altest; falling back to MIDI 1.0 [Fri Jan 12 19:05:32 2024] usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008
(In reply to mksafavi from comment #24) > I set /etc/modprobe.d/alsa.conf to this: > options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x800 > > It boots just fine. I don't get the "usb 1-6: 2:1: cannot set freq 44100 > (v2/v3): err -110" error. > Should it also affect the "cannot get clock validity" error? I'm going to > keep it running to see if I notice anything. They are probably related. Do you still get errors during normal use? If this still happens, please post the kernel log.
I you are still getting "cannot get clock validity" error during normal use, then this device probably also need the same quirk as MOTU Microbook IIc. The only problem is that we cannot test this quirk with the boot quirk without recompiling the kernel with a patch applied.
(In reply to Alexander Tsoy from comment #25) > They are probably related. Do you still get errors during normal use? If > this still happens, please post the kernel log. In the past 3-4 days I didn't get it during normal using this config: options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x800 Though it happened once during boot so I had to powercycle it. here's the log: Jan 14 05:15:14 archlinux kernel: usb 1-6: new high-speed USB device number 4 using xhci_hcd Jan 14 05:15:14 archlinux kernel: usb 1-6: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 Jan 14 05:15:14 archlinux kernel: usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 14 05:15:14 archlinux kernel: usb 1-6: Product: M4 Jan 14 05:15:14 archlinux kernel: usb 1-6: Manufacturer: MOTU Jan 14 05:15:14 archlinux kernel: usb 1-6: SerialNumber: M4AE0C9064 Jan 14 05:15:15 archlinux mtp-probe[326]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6" Jan 14 05:15:15 archlinux kernel: cdc_acm 1-6:1.5: ttyACM0: USB ACM device Jan 14 05:15:20 archlinux kernel: usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 Jan 14 05:15:40 archlinux kernel: usb 1-6: parse_audio_format_rates_v2v3(): unable to find clock source (clock -110) Jan 14 05:15:45 archlinux kernel: usb 1-6: Quirk or no altest; falling back to MIDI 1.0 Jan 14 05:15:45 archlinux kernel: usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 Jan 14 05:15:45 archlinux kernel: usb 1-6: USB disconnect, device number 4 Jan 14 05:15:45 archlinux (udev-worker)[305]: controlC3: /usr/lib/udev/rules.d/78-sound-card.rules:5 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.0/sound/card3/controlC3/../uevent}, ignoring: No such file or directory Jan 14 05:15:46 archlinux kernel: usb 1-6: new high-speed USB device number 7 using xhci_hcd Jan 14 05:15:46 archlinux kernel: usb 1-6: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 Jan 14 05:15:46 archlinux kernel: usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 14 05:15:46 archlinux kernel: usb 1-6: Product: M4 Jan 14 05:15:46 archlinux kernel: usb 1-6: Manufacturer: MOTU Jan 14 05:15:46 archlinux kernel: usb 1-6: SerialNumber: M4AE0C9064 Jan 14 05:15:46 archlinux kernel: usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 Jan 14 05:15:50 archlinux kernel: usb 1-6: Quirk or no altest; falling back to MIDI 1.0 Jan 14 05:15:50 archlinux kernel: usb 1-6: device (07fd:000b): applying quirk alias 07fd:0008 Jan 14 05:15:50 archlinux kernel: cdc_acm 1-6:1.5: ttyACM0: USB ACM device Jan 14 05:15:50 archlinux mtp-probe[1502]: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6" Jan 14 05:15:50 archlinux mtp-probe[1504]: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6"
(In reply to Alexander Tsoy from comment #26) > I you are still getting "cannot get clock validity" error during normal use, > then this device probably also need the same quirk as MOTU Microbook IIc. > The only problem is that we cannot test this quirk with the boot quirk > without recompiling the kernel with a patch applied. Hello, I am back again. How can I help test this, and what combinations should I try? Currently I'm running an unpatched stock kernel on Fedora 39, using the following quirks in alsa.conf: options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20 Am I correct in assuming that the quirk flag does nothing, since I haven't patched the kernel with the skip_clock_selector_set patch? My current dmesg output log: [ 1.631578] usb 1-11: new high-speed USB device number 4 using xhci_hcd [ 1.759476] usb 1-11: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 [ 1.759479] usb 1-11: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1.759480] usb 1-11: Product: M4 [ 1.759481] usb 1-11: Manufacturer: MOTU [ 1.759482] usb 1-11: SerialNumber: M4AE07DD64 [ 4.010329] usb 1-11: device (07fd:000b): applying quirk alias 07fd:0008 [ 13.358655] usb 1-11: 1:1: cannot set freq 192000 (v2/v3): err -110 [ 13.361184] usb 1-11: Quirk or no altest; falling back to MIDI 1.0 [ 13.361957] usb 1-11: device (07fd:000b): applying quirk alias 07fd:0008 Although it says "cannot set freq 192000 (v2/v3): err -110" the interface still works through multiple shutdowns and reboots, but that has happened before, so I can't say for sure whether it'll keep working. I'll keep you posted if something changes. In the meantime, let me know what combinations I can try with respect to kernel patching and applied quirks.
(In reply to mksafavi from comment #27) > (In reply to Alexander Tsoy from comment #25) > > They are probably related. Do you still get errors during normal use? If > > this still happens, please post the kernel log. > > In the past 3-4 days I didn't get it during normal using this config: > options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x800 > Though it happened once during boot so I had to powercycle it. > > here's the log: > > Jan 14 05:15:14 archlinux kernel: usb 1-6: new high-speed USB device number > 4 using xhci_hcd > Jan 14 05:15:14 archlinux kernel: usb 1-6: New USB device found, > idVendor=07fd, idProduct=000b, bcdDevice= 2.04 > Jan 14 05:15:14 archlinux kernel: usb 1-6: New USB device strings: Mfr=1, > Product=2, SerialNumber=3 > Jan 14 05:15:14 archlinux kernel: usb 1-6: Product: M4 > Jan 14 05:15:14 archlinux kernel: usb 1-6: Manufacturer: MOTU > Jan 14 05:15:14 archlinux kernel: usb 1-6: SerialNumber: M4AE0C9064 > Jan 14 05:15:15 archlinux mtp-probe[326]: checking bus 1, device 4: > "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6" > Jan 14 05:15:15 archlinux kernel: cdc_acm 1-6:1.5: ttyACM0: USB ACM device > Jan 14 05:15:20 archlinux kernel: usb 1-6: device (07fd:000b): applying > quirk alias 07fd:0008 > Jan 14 05:15:40 archlinux kernel: usb 1-6: parse_audio_format_rates_v2v3(): > unable to find clock source (clock -110) > Jan 14 05:15:45 archlinux kernel: usb 1-6: Quirk or no altest; falling back > to MIDI 1.0 > Jan 14 05:15:45 archlinux kernel: usb 1-6: device (07fd:000b): applying > quirk alias 07fd:0008 > Jan 14 05:15:45 archlinux kernel: usb 1-6: USB disconnect, device number 4 > Jan 14 05:15:45 archlinux (udev-worker)[305]: controlC3: > /usr/lib/udev/rules.d/78-sound-card.rules:5 Failed to write > ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.0/sound/card3/ > controlC3/../uevent}, ignoring: No such file or directory > Jan 14 05:15:46 archlinux kernel: usb 1-6: new high-speed USB device number > 7 using xhci_hcd > Jan 14 05:15:46 archlinux kernel: usb 1-6: New USB device found, > idVendor=07fd, idProduct=000b, bcdDevice= 2.04 > Jan 14 05:15:46 archlinux kernel: usb 1-6: New USB device strings: Mfr=1, > Product=2, SerialNumber=3 > Jan 14 05:15:46 archlinux kernel: usb 1-6: Product: M4 > Jan 14 05:15:46 archlinux kernel: usb 1-6: Manufacturer: MOTU > Jan 14 05:15:46 archlinux kernel: usb 1-6: SerialNumber: M4AE0C9064 > Jan 14 05:15:46 archlinux kernel: usb 1-6: device (07fd:000b): applying > quirk alias 07fd:0008 > Jan 14 05:15:50 archlinux kernel: usb 1-6: Quirk or no altest; falling back > to MIDI 1.0 > Jan 14 05:15:50 archlinux kernel: usb 1-6: device (07fd:000b): applying > quirk alias 07fd:0008 > Jan 14 05:15:50 archlinux kernel: cdc_acm 1-6:1.5: ttyACM0: USB ACM device > Jan 14 05:15:50 archlinux mtp-probe[1502]: checking bus 1, device 7: > "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6" > Jan 14 05:15:50 archlinux mtp-probe[1504]: checking bus 1, device 7: > "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6" Great to see that it's not just me facing this problem. What's your setup with respect to kernel patches and applied quirks? And is it still working on your end, or does your system still lock up because of the Motu M4? What exactly happens when the Motu M4 doesn't work? On my end, I get "dummy output" and e.g. if I try to right click in Firefox, Firefox will crash and ask to either wait or force quit.
(In reply to lorentzen.alexander from comment #29) > Great to see that it's not just me facing this problem. xD > What's your setup with respect to kernel patches and applied quirks? And is > it still working on your end, or does your system still lock up because of > the Motu M4? to recap all the configs that I have tested: 1. no quirks applied I get the "cannot set freq 44100 (v2/v3): err -110" and boots to the desktop but all the windows freeze. Powering off the interface unfreezes the desktop and "uac_clock_source_is_valid(): cannot get clock validity for..." is printed. Powering on the interface it gets detected and works fine. 2. options snd-usb-audio quirk_alias=07fd000b:07fd0008" Boots without any errors. gets detected and works fine. There are occasional but rare "cannot get clock validity.." errors during normal use. 3. options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20" I get the "cannot set freq 44100 (v2/v3): err -110" and it doesn't boot into the desktop. power cycling has the same behavior as no quirks. 4. options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x800" Boots without any error. gets detected and works fine but sometimes freezes during boot and needs power cycling. So right now I'm running "options snd-usb-audio quirk_alias=07fd000b:07fd0008" and Jack audio. I don't have any issues during boot and normal use. > What exactly happens when the Motu M4 doesn't work? On my end, I get "dummy > output" and e.g. if I try to right click in Firefox, Firefox will crash and > ask to either wait or force quit. I think it's dependent on the userspace configurations. On my machine i3wm loads but the windows don't render until I turn off the interface. If I disable the pulseaudio systemd service my desktop won't freeze even when no quirks are applied. Although I rarely get "cannot get clock validity" errors during normal use but it only happens when I'm running PulseAudio. I never got this error while running Jack. What's your desktop environment behavior after boot without quirks? (In reply to lorentzen.alexander from comment #28) > Although it says "cannot set freq 192000 (v2/v3): err -110" the interface > still works through multiple shutdowns and reboots I also noticed that mine works fine during reboots but fails on shutdowns. For testing the quirks I made sure to shutdown every time. > In the meantime, let me know what combinations I can try with respect to > kernel patching and applied quirks. There's the MOTO Microbook IIc patch that Alexander Tsoy mentioned in Comment #26. Unfortunately I can't patch my kernel right now as this is the only machine I have access to. It would be great if you could give it a try.
Just to avoid unnecessary debugging, the GUI lockups are not directly due to a kernel bug but rather because the audio daemon (PulseAudio or PipeWire) is waiting on the audio hardware. It might be contentious to say so but the audio daemon waiting on hardware should not be an issue for the GUI as a whole but for some reason something perhaps via D-Bus is coupling GUI ticks with audio daemon ticks, which results in the observed GUI issues, when the audio daemon is stuck and does not advance its processing. In other words, two different issues, so just focus on your audio problem and ignore the GUI hangs for this particular bug. ;)
Created attachment 305737 [details] Non-working, with quirk alias.
Created attachment 305738 [details] Non-working, no quirks of any sort.
Created attachment 305739 [details] Working, quirk alias and quirk flags.
Created attachment 305740 [details] Working, quirk flags only.
Created attachment 305741 [details] Working, both quirk flags only.
I've now uploaded the outputs of a handful of different combinations. All the testing is done on a fully updated Fedora Workstation 39, stock kernel 6.6.11, GNOME 45.3. I did not modify the kernel, meaning I did not use any patches. What I can conclude from this: - quirk flag "0x800" helps a little, but doesn't fix it. - quirk flag "0x20" seems to fix it entirely, with and without the quirk alias. - "cannot set freq 48000 (v2/v3): err -110" and "cannot set freq 192000 (v2/v3): err -110" would appear from time to time, but with "0x20" it would still work. Quirk flag "0x20" has persisted through multiple reboots and full shutdowns (cold and soft). Here's an alsa-info.sh output from when it does not work (using "quirk_alias=07fd000b:07fd0008 quirk_flags=0x800"): https://alsa-project.org/db/?f=23f72b76508004b541286ef3fb2896c9851c8d8b Here's an alsa-info.sh output from when it does work (using "quirk_flags=0x20"): https://alsa-project.org/db/?f=e4087453bda7edaccc2faceed76fc8adc6b3e108 Here's another one, where it also works (using "quirk_flags=0x20,0x800"): https://alsa-project.org/db/?f=a59e78dfb878227f2758709df3beebdf8040ac62 And after several reboots and shutdowns (with "cannot set freq 48000 (v2/v3): err -110" error, while it still works): https://alsa-project.org/db/?f=729d35f7f4bf1639ce00a70bbfa20b7e131fc73b
(In reply to mksafavi from comment #30) > (In reply to lorentzen.alexander from comment #29) > 1. no quirks applied > I get the "cannot set freq 44100 (v2/v3): err -110" and boots to the desktop > but all the windows freeze. > Powering off the interface unfreezes the desktop and > "uac_clock_source_is_valid(): cannot get clock validity for..." is printed. > Powering on the interface it gets detected and works fine. > > 2. options snd-usb-audio quirk_alias=07fd000b:07fd0008" > Boots without any errors. gets detected and works fine. > There are occasional but rare "cannot get clock validity.." errors during > normal use. > > 3. options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20" > I get the "cannot set freq 44100 (v2/v3): err -110" and it doesn't boot into > the desktop. power cycling has the same behavior as no quirks. > > 4. options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x800" > Boots without any error. gets detected and works fine but sometimes freezes > during boot and needs power cycling. If possible, can you try these combinations: - options snd-usb-audio quirk_flags=0x20 - options snd-usb-audio quirk_flags=0x800 - options snd-usb-audio quirk_flags=0x20,0x800 - options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20,0x800 Also, I still get "cannot set freq 44100 (v2/v3): err -110" with "0x800", but it does seem more infrequent. If you have the time, remember to test through multiple reboots/shutdowns. The way I did it was: 1. Apply the quirks. 2. Shutdown, wait 1 minute and boot up again. 3. Check all the outputs of commands (see commands below). 4. Reboot. 5. Repeat step 3. 6. Force shutdown computer (by holding the power-button until powers off). 7. Wait 1 minute and boot again. 8. Repeat step 3. 9. Reboot, and repeat step 3 one last time. The commands I used: - aplay -l - sudo dmesg - sudo fuser -v /dev/snd/* - spa-acp-tool -vvvv lv -c 0 Refer to attached log files to see example outputs of the commands above.
(In reply to lorentzen.alexander from comment #37) > - quirk flag "0x20" seems to fix it entirely, with and without the quirk > alias. (In reply to mksafavi from comment #30) > 3. options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20" > I get the "cannot set freq 44100 (v2/v3): err -110" and it doesn't boot into > the desktop. power cycling has the same behavior as no quirks. This contradicts to comment #37 :( Could you retest with just quirk_flags=0x20?
(In reply to lorentzen.alexander from comment #38) > - options snd-usb-audio quirk_flags=0x20,0x800 > - options snd-usb-audio quirk_alias=07fd000b:07fd0008 quirk_flags=0x20,0x800 If you want to apply multiple quirks then sum up corresponding bits: quirk_flags=0x820
(In reply to Alexander Tsoy from comment #40) > (In reply to lorentzen.alexander from comment #38) > > - options snd-usb-audio quirk_flags=0x20,0x800 > > - options snd-usb-audio quirk_alias=07fd000b:07fd0008 > quirk_flags=0x20,0x800 > If you want to apply multiple quirks then sum up corresponding bits: > quirk_flags=0x820 Ah, thanks! But I don't think 0x800 does anything on my end. It has been a two days now and I've had zero problems with the interface. This is using just: options snd-usb-audio quirk_flags=0x20 with the stock kernel.
(In reply to lorentzen.alexander from comment #42) > It has been a two days now and I've had zero problems with the interface. > This is using just: > > options snd-usb-audio quirk_flags=0x20 I also think it's the way to go although it doesn't fix all the problems with the card. It is basically equivalent to the patch from comment 16. I'd like to get some more feedback from @mksafavi before sending it to alsa-devel. Maybe you even have different hardware revisions (Atmel vs NXP). @mksafavi please upload alsa-info.sh output from your system. See comment 10 for example.
Created attachment 305745 [details] working_with_0x20.txt I tested "options snd-usb-audio quirk_flags=0x20" over multiple shutdowns and it seems to work fine. I couldn't make time to test the other combinations. I'll try to test them by tomorrow. I also attached the alsa-info.sh output to this email. On Tue, Jan 23, 2024 at 12:35 AM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217601 > > --- Comment #43 from Alexander Tsoy (alexander@tsoy.me) --- > (In reply to lorentzen.alexander from comment #42) > > It has been a two days now and I've had zero problems with the interface. > > This is using just: > > > > options snd-usb-audio quirk_flags=0x20 > I also think it's the way to go although it doesn't fix all the problems > with > the card. It is basically equivalent to the patch from comment 16. I'd > like to > get some more feedback from @mksafavi before sending it to alsa-devel. > Maybe > you even have different hardware revisions (Atmel vs NXP). > > @mksafavi please upload alsa-info.sh output from your system. See comment > 10 > for example. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to mksafavi from comment #44) > Created attachment 305745 [details] > working_with_0x20.txt Thanks! USB descriptors are slightly different, but I believe the main problem is the same and patch from comment 16 should help as well as quirk_flags=0x20
(In reply to Alexander Tsoy from comment #45) > Thanks! USB descriptors are slightly different, but I believe the main > problem is the same and patch from comment 16 should help as well as > quirk_flags=0x20 Do you want me to test the skip clock selector patch? And if yes, should I apply any quirks with it or just remove the alsa.conf in /etc/modprobe.d/ when testing the patch?
(In reply to lorentzen.alexander from comment #46) > Do you want me to test the skip clock selector patch? And if yes, should I > apply any quirks with it or just remove the alsa.conf in /etc/modprobe.d/ > when testing the patch? No quirks are needed with the patch, so yes, just remove /etc/modprobe.d/alsa.conf. As I already mentioned, this patch should be equivalent to quirk_flags=0x20 for your card.
Created attachment 305755 [details] Skip clock selector patch, no quirks.
(In reply to Alexander Tsoy from comment #47) > No quirks are needed with the patch, so yes, just remove > /etc/modprobe.d/alsa.conf. As I already mentioned, this patch should be > equivalent to quirk_flags=0x20 for your card. I've tested your patch. It worked on the first boot, the first reboot, the first hard reboot (holding the power-button until power-off and then booting again). But the first reboot after that it stopped working again, showing "dummy output" in GNOME sound settings. However, after a few minutes it started working again (on the same boot) - like it was delayed or something I still get "cannot set freq 48000 (v2/v3): err -110", but that error didn't prevent it from working. Refer to the log file I attached for the full info dump from all commands. If you just want to look at alsa-info outputs, here they are: First boot: https://alsa-project.org/db/?f=72f0b5efe0931038af7975acca7a49f5d68cf6f1 On reboot: https://alsa-project.org/db/?f=a725d2dafee03df5801d1e53f951e0236a8eae01 After several hard reboots and soft reboots: https://alsa-project.org/db/?f=8e711eccaf4a86dab48c4a007068a521e36d4802 After next soft reboot (stops working): https://alsa-project.org/db/?f=16df94f865f97dbd51172b9e403c22217af8cdd9 Starts working again (on same boot as above, after around 2-5 min): https://alsa-project.org/db/?f=a44b5ddcdd2bd0ef02ee6014cf5f726fa5599265
(In reply to lorentzen.alexander from comment #49) > I still get "cannot set freq 48000 (v2/v3): err -110", but that error didn't > prevent it from working. Yeah, I will look at how to debug this further when I have more time.
For good measure I also tried the skip clock selector patched kernel with quirk "0x800" and after 6-7 soft/hard reboots and shutdowns I still made "cannot set freq 48000 (v2/v3): err -110" appear: [ 1.644552] usb 1-11: new high-speed USB device number 4 using xhci_hcd [ 1.771459] usb 1-11: New USB device found, idVendor=07fd, idProduct=000b, bcdDevice= 2.04 [ 1.771463] usb 1-11: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1.771465] usb 1-11: Product: M4 [ 1.771467] usb 1-11: Manufacturer: MOTU [ 1.771468] usb 1-11: SerialNumber: M4AE07DD64 [ 4.030528] usb 1-11: Quirk or no altest; falling back to MIDI 1.0 [ 15.759594] usb 1-11: 2:1: cannot set freq 48000 (v2/v3): err -110 [ 20.761618] usb 1-11: 2:1: cannot set freq 48000 (v2/v3): err -110
One more thing to try: - quirk_flags=0x100 (if the patch from comment 16 was applied) - quirk_flags=0x120 (for unpatched kernel) This quirk adds 20ms delay between control messages
(In reply to Alexander Tsoy from comment #52) > One more thing to try: > - quirk_flags=0x100 (if the patch from comment 16 was applied) > - quirk_flags=0x120 (for unpatched kernel) > > This quirk adds 20ms delay between control messages Well well, I think it's fixed now! Content of "/etc/modprobe.d/alsa.conf": options snd-usb-audio quirk_flags=0x120 There were no audio delays on boot-up, meaning the interface audio was available from the get-go. Sometimes it would take a few seconds for the interface to pop up (judging from the sound/audio icon in the top panel of GNOME, and from GDM as well). This doesn't happen anymore, as it appears at all times now, no delays. This was somewhat critical for audio applications depending on the interface sinks and sources early on (like EasyEffects). Additionally, through 8 consecutive soft/hard reboots I was not able to reproduce "cannot set freq 48000 (v2/v3): err -110". Not even once! One thing I should mention is that below output ("aplay -l") will change between "Subdevices: 0/1" and "Subdevices: 1/1": **** List of PLAYBACK Hardware Devices **** card 0: M4 [M4], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 **** List of PLAYBACK Hardware Devices **** card 0: M4 [M4], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 This is not something new, as it has happened through all the different configurations. Another thing I should mention, which has also been persistent, is the output of "spa-acp-tool -vvvv lv -c 0". The first few times it's run it'll act as if only the Pro Audio profile is available (card 0: profiles:2 devices:2 ports:0), which is false since all the UCM profiles are available. However, re-running the command 2-10 times will eventually make it display the full output, showing "card 0: profiles:4 devices:12 ports:10". Refer to the two log files for above. If you're only interested in the alsa outputs from "quirk_flags=0x120", here they are: First boot: https://alsa-project.org/db/?f=ef59d88c9cdfc505f84abce180cb8661fde9e2e7 On reboot: https://alsa-project.org/db/?f=d0eb10887f9b730ce0b5a5583210dd82ae768834 After first hard reboot: https://alsa-project.org/db/?f=9f8ac786df6fd0f86f4eb9429c7ec8e9463bbd52 After hard reboot and soft reboot: https://alsa-project.org/db/?f=03a5ff60ae266d70c6455e374ccd810e2901b8fb After several hard reboot and soft reboot: https://alsa-project.org/db/?f=6c5d807203f2a7169760a1cbe4c1da6d6ebeddcf After many reboots (subdevices 1/1): https://alsa-project.org/db/?f=135d2ca43425cd0c0f2fcd739a5bae2cbdce85d5
Created attachment 305769 [details] Fully working config with quirk "0x120". No "cannot set freq" errors through 8 reboots.
Created attachment 305770 [details] Initial "spa-acp-tool -vvvv lv -c 0" output showing a limited amount of profiles and devices.
Please also try quirks with shorter delays: - quirk_flags=0x220 (1-2ms delay) - quirk_flags=0x420 (5-6ms delay) If you will have success with the first variant, no need to try the second. We just need to find minimal delay that would make the card stable.
Created attachment 305771 [details] Fully working config with quirk "0x220". No "cannot set freq" errors through 6 reboots.
(In reply to Alexander Tsoy from comment #56) > Please also try quirks with shorter delays: > - quirk_flags=0x220 (1-2ms delay) > - quirk_flags=0x420 (5-6ms delay) > > If you will have success with the first variant, no need to try the second. > We just need to find minimal delay that would make the card stable. Through 6 consecutive soft/hard reboots and shutdowns, using: options snd-usb-audio quirk_flags=0x220 I couldn't reproduce the "cannot set freq 48000 (v2/v3): err -110". As per usual the log file is attached, and if you just want the alsa-info outputs: First boot: https://alsa-project.org/db/?f=19b5176b4bbb26cd9f11fcd64ca0c2857b9c35bd On reboot: https://alsa-project.org/db/?f=1f788159cbf0fef501b51b7c71a861a0b997d28b After first hard reboot: https://alsa-project.org/db/?f=735957b77a0c3f0cc1d1ee7b21837cb65df1d7b0 After hard reboot and soft reboot: https://alsa-project.org/db/?f=1c20a5d429922b528016a59285a15ede96134e60 After several hard reboot and soft reboot: https://alsa-project.org/db/?f=1dd3de33d9cb1b6e13ffaf599b820ddb63335050 After many reboots: https://alsa-project.org/db/?f=e4476ad301d390b8914072c68a4a14f960ff0122 "aplay -l" still switches between "Subdevices: 0/1" and "Subdevices: 1/1", but I don't even know if that's an issue or intended behavior. It seems to happen only on reboots, not shutdowns.
Created attachment 305772 [details] working_with_0x220.txt working alsa-info.sh log with quirk_flags=0x220
(In reply to lorentzen.alexander from comment #53) > Another thing I should mention, which has also been persistent, is the > output of "spa-acp-tool -vvvv lv -c 0". The first few times it's run it'll > act as if only the Pro Audio profile is available (card 0: profiles:2 > devices:2 ports:0), which is false since all the UCM profiles are available. > However, re-running the command 2-10 times will eventually make it display > the full output, showing "card 0: profiles:4 devices:12 ports:10". > Trying _ucm0001.hw:M4 with SND_PCM_NO_AUTO_FORMAT ... > open '/dev/snd/pcmC0D0p' failed (-16) > Error opening PCM device _ucm0001.hw:M4: Device or resource busy Not sure if this is a driver issue or not. You can try `lsof /dev/snd/pcmC0D0p` when you see these errors. Maybe something in userspace gains exclusive access.
I tried the control message delay flags. I hard rebooted each variant a handful of times and had no issues during boot time. I attached the alsa-info log after boot with quirk_flags=0x220. (In reply to Alexander Tsoy from comment #56) > Please also try quirks with shorter delays: > - quirk_flags=0x220 (1-2ms delay) > - quirk_flags=0x420 (5-6ms delay) > > If you will have success with the first variant, no need to try the second. > We just need to find minimal delay that would make the card stable. Wondering, should this affect normal use behavior? with some applications that use alsa directly, I get pops and crackles in audio when starting to play. It seems like it also megitates that. I switched between 0x20 and 0x220 multiple times. I heard virtually no pops with 0x220 and I got the pops with 0x20 or without any flags. Is it related? or it's a placebo on my end :)
(In reply to mksafavi from comment #61) > Wondering, should this affect normal use behavior? > with some applications that use alsa directly, I get pops and crackles in > audio when starting to play. > It seems like it also megitates that. > I switched between 0x20 and 0x220 multiple times. I heard virtually no pops > with 0x220 and I got the pops with 0x20 or without any flags. > Is it related? or it's a placebo on my end :) Nobody can tell for sure as the card is a black box. In theory it is possible that too frequent control messages puts the device in some undesired state that leads to audio synchronisation issues due to buggy firmware.
(In reply to mksafavi from comment #61) > Wondering, should this affect normal use behavior? > with some applications that use alsa directly, I get pops and crackles in > audio when starting to play. > It seems like it also megitates that. > I switched between 0x20 and 0x220 multiple times. I heard virtually no pops > with 0x220 and I got the pops with 0x20 or without any flags. > Is it related? or it's a placebo on my end :) The immense amount of xruns happening pre-quirks have also been eliminated completely on my end. So maybe there's something to it? It would go up in the hundreds after a while using Ardour. Now I've only gotten a 1-2 using sample size 48000Hz at a 256 clock rate (this is what Windows defaults to on the M4 after installing the firmware/drivers for it), and default periods wrt. PipeWire. I wonder if I could go lower? What are you using mksafavi? (In reply to Alexander Tsoy from comment #62) > Nobody can tell for sure as the card is a black box. In theory it is > possible that too frequent control messages puts the device in some > undesired state that leads to audio synchronisation issues due to buggy > firmware. Can we find someone who has a Motu M2 or M6? I suppose these quirks may very well carry over?
(In reply to lorentzen.alexander from comment #63) > Can we find someone who has a Motu M2 or M6? I suppose these quirks may very > well carry over? As far as I understand, all models (M2/M4/M6) of the same revision share the same firmware and all features like number of channels are detected at runtime. So they should behave exactly the same. By the way, patches have been accepted upstream and may be even will find their way into 6.8. https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-linus
(In reply to lorentzen.alexander from comment #63) > What are you using mksafavi? I usually record at 48kz and 256samples with reaper connecting with alsa. In my case they got way lower but it didn't fix the issue completely. without the quirks it was consistently broken and every time clicked play it would give xruns. after the quirk it happens much rarely. Though I had no issues using jack. even the normal use problems only happened when I was running desktop apps with pulse audio alone. I did test Ardour for a few hours and it was more stable. I personally wont go lower than that. 48khz and 256samples already has an usable latency. (In reply to Alexander Tsoy from comment #64) > By the way, patches have been accepted upstream and may be even will find > their way into 6.8. > https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for- > linus Awesome.
I know it's confusing but there's more to the audio latency than just the numbers shown for the client configuration, so best to think of them as guidelines for your particular setup and not assume that it's the whole picture or that you can directly compare different setups. Ultimately proof is in the pudding, so you need to actually measure the loopback latency, if you really care. Or just be happy with what it is, if it's not perceivably bad.
There are also some insights from MOTU engineer about implementation of implicit feedback mode in linux. Not sure if this is still the case. https://linuxmusicians.com/viewtopic.php?p=149520#p149520
(In reply to Niklāvs Koļesņikovs from comment #66) > I know it's confusing but there's more to the audio latency than just the > numbers shown for the client configuration, so best to think of them as > guidelines for your particular setup and not assume that it's the whole > picture or that you can directly compare different setups. > > Ultimately proof is in the pudding, so you need to actually measure the > loopback latency, if you really care. Or just be happy with what it is, if > it's not perceivably bad. Personally the latency has always been acceptable for me, even with cheaper equipment. so I never bothered testing it. but you got me curious and I wanted an excuse to use that extra pair of inputs I have on the interface xD Let me know if I'm doing it wrong. Here's what I did: I connected the channel 3 output to channel 3 input. Then played a clap sample through the output and recorded the input channel. I also disabled latency compensation in my daw to not move things around. comparing the beginning transients, I got 11ms rounded to the closest ms. ALSA reported latency was 5.3in/5.3out for the total of 10.6ms which is close to what I got. I also tried adding some vst plugins to see how they would effect the latency. Which surprisingly was really low I couldn't get it to go past 15-20ms. (In reply to Alexander Tsoy from comment #62) > Nobody can tell for sure as the card is a black box. In theory it is > possible that too frequent control messages puts the device in some > undesired state that leads to audio synchronisation issues due to buggy > firmware. To bring it back to the topic of M4, does the added delays by the quirk affect the audio latency?
(In reply to mksafavi from comment #68) > To bring it back to the topic of M4, does the added delays by the quirk > affect the audio latency? No, endpoints manipulations and URB submissions should not be influenced by these dalays AFAICT
The most common method for measuring roundtrip latency is the jack_iodelay tool but the way you did it is reasonable, too. Regarding any added latency, you'd see it in the roundtrip, which in your case would be 11-10.6 or about 0.4 ms +/- any measurement error on your side e.g. misreading the waveform timestamps. You can probably assume that it's 0.2 ms extra atency for input and output each, however the actual split of those 0.4 ms is essentially unknowable in a home setting. Perhaps a more important metric, though, would be excessive jitter observed in jack_iodelay measurements, since it can indicate some kind of firmware or driver bug. Or an issue with PC's scheduling.