PipeWire fails to take control of USB audio
- PipeWire version:
0.3.71
- Distribution and distribution version:
Fedora Linux 38 (Workstation Edition)
- Desktop Environment:
GNOME 44.2
- Kernel version:
6.3.8-200.fc38
Hardware:
- USB audio interface, DAC: Mark of the Unicorn M4 (MOTU M4)
Description of Problem:
(Please let me know if I should attach additional logs/command outputs.)
Upon boot-up my USB audio interface fails to be recognized by PipeWire and applications. In this state it will cause applications to hang, e.g. Firefox which will refuse to play videos and music, additionally Firefox will also crash/hang as soon as I right-click in the app. Applications like Audacity and Ardour may not even open in this state.
As soon as my USB audio interface is physically shut off (by using the power button on the back), all applications will start to function optimally.
While in the non-working state, GNOME sound settings will display one of two things:
- Output Device:
Dummy Output
and Input Device:No Input Devices
- Output Device:
No Output Device
and Input Device:No Input Devices
In the non-working state, PipeWire will continue to hang, so commands such as pactl list cards
won't execute immediately, and will only do so if the state changes.
Occasionally, after a good while, the interface will be in a semi-working state. However, only the profiles Pro Audio
and Off
will be available.
I want to be able to utilize the Hi-Fi
profile at all times.
Sometimes spa-acp-tool -vvvv lv -c 0
will output: Device or resource busy
.
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.
What I've tried so far:
- 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
andXHCI Hand-Off
, as well asPCIe 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).
This is a follow-up to my previous issue, which is effectively the same: #3143
What stood out to me the most with regards to the logging, was:
- dmesg:
parse_audio_format_rates_v2v3(): unable to find clock source (clock -110)
- dmesg:
cannot set freq 48000 (v2/v3): err -110
- spa-acp-tool:
Error opening PCM device _ucm0001.hw:M4: Device or resource busy
How Reproducible:
On practically every boot. Occasionally it will work optimally on normal boot-ups, but that is insanely rare. I've yet to find any patterns that help explain this behavior.
Steps to Reproduce:
Below I've listed different methods on how to reproduce the issue, putting the interface into the non-working state:
- Booting, rebooting, and logging out.
- Switching audio profiles (e.g. through pavucontrol).
- Throwing many different audio-dependent applications at it simultaneously, like Ardour, Firefox, EasyEffects, video games, Discord.
Actual Results:
MOTU M4 is in a limited state on boots and reboots, additionally it can cause applications to hang at random times.
Expected Results:
The MOTU M4 working as expected, able to utilize all profiles and handle a diverse range of audio tasks without crashing/hanging applications that use it.
Additional Info (as attachments):
-
pw-dump > pw-dump.log
: pw-dump.log -
spa-acp-tool -vvvv lv -c 0 > spa-acp-tool.log
: spa-acp-tool.log -
sudo fuser -v /dev/snd/* > fuser-output.log
: fuser-output.log -
ls -ltr /dev/snd/ > dev-snd.log
: dev-snd.log -
lsusb -vt > lsusb-output.log
: lsusb-output.log -
aplay -Ll > aplay-output.log
: aplay-output.log
(Additional logs can be found in my previous issue.)