Summary: upgrading Linux from 5.15.13 to a newer version was required to make playback through Behringer U-PHORIA UMC202HD work again. Even with the new version, the quirk flags needed for this device didn't seem to get applied automatically, despite them being present in the source code. Manual application through
modprobe command-line arguments or its configuration file works fine.
Read the original blog post: Making Behringer UMC202HD Work With Linux
Two days ago I tried using Behringer U-PHORIA UMC202HD for audio playback and noticed that the workaround to make it not choppy wasn't working any more. This post is a journal of what I went through and how the issue was solved.
It had been a while since I used UMC202HD for audio playback. I don't think I have tried it since upgrading to Ubuntu 22.04 from 20.04 (which also caused the switch from PulseAudio to PipeWire).
The playback was choppy without
implicit_fb=1 as usual, and there was no audible output at all with
implicit_fb=1. The playback going silent with implicit buffer was a known issue, but switching the profiles and devices back and forth in pavucontrol would solve the issue. This time it wasn't happening. Tried both the usual apps and
speaker-test; audio level indicators in pavucontrol were clearly indicating there was output.
No unusual messages in
System: Linux 5.15.13, Ubuntu 22.04.1 LTS, KDE Plasma Desktop, PulseAudio (on PipeWire 0.3.59, according to
I still have no idea why the workaround stopped working, without having a major kernel upgrade. Maybe it had something to do with other components that were upgraded or switched as part of Ubuntu upgrade. Or it was due to some minor kernel upgrade.
A comment posted by Greenwave_1 six or seven months ago in
a reddit thread
says that adding
options snd_usb_audio quirk_flags=0x20010 to
/etc/modprobe.d/snd_usb_audio.conf should work for Linux 5.18.6 according to
a kernel bugzilla thread.
I made the change, disconnected the device, ran
modprobe -r snd_usb_audio followed by
modprobe snd_usb_audio, which made no difference (i.e., still choppy without
implicit_fb and silent with implicit_fb).
It was mentioned in the reddit comment that the solution would not work for
Linux 5.15. Seemed true because
dmesg was saying
implicit_fb=0 even with
0x20010 which should translate to
QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_GENERIC_IMPLICIT_FB
according to the bugzilla thread. Maybe the numeric value is different for
Linux 5.15.13. But I didn't want to spend time digging more because it wasn't
working even with
modprobe snd_usb_audio implicit_fb=1
(which it used to), and as was mentioned in the bugzilla thread, 5.15 was too
old to debug.
So I decided to simply try "v5.19 Mainline Test" from here: https://kernel.ubuntu.com/%7Ekernel-ppa/mainline/v5.19/.
Now it works fine (Linux 5.19.0-051900-generic), either with
modprobe snd_usb_audio implicit_fb=1 or with the permanent addition of the flags to modprobe.d configuration file.
The Puzzle: Quirks Not Applied Automatically
The problem is, the flags are not applied automatically despite 5.19 having the quirks baked in. This is what
modprobe snd_usb_audio dyndbg==p says:
[65105.580355] usb 3-4: Open EP 0x8, iface=1:1, idx=0 [65105.580368] usb 3-4: channels=2, rate=48000, format=S32_LE, period_bytes=4096, periods=64, implicit_fb=0 [65105.580377] usb 3-4: Open EP 0x84, iface=1:1, idx=1 [65105.580383] usb 3-4: channels=2, rate=48000, format=S32_LE, period_bytes=4096, periods=64, implicit_fb=0
modprobe snd_usb_audio dyndbg==p implicit_fb=1, it reports
Open EP 0x8.
I'm still puzzled by the quirks not being applied automatically. I remember having faced the same issue back when I was editing the kernel code and building it myself to see if I could come up with a patch. I dismissed the issue back then because I seemed to be doing something wrong and loading the old module instead of the edited one. Now it's a question again. In case you are wondering, yes, I've made sure the USB ids in the code and
lsusb do match.
My Choice of Kernel Version
On 2023-01-15, only while editing this to a blog post did I reconsider my choice of the newer kernel version. And this is when I also decided to actually check if the quirk was already present in the tree. 6.1.6 was the latest stable version and 5.15.88 was the latest longterm version. Turned out the quirk flags were already present in 5.15.88. I chose 5.19 simply because the bugzilla thread was recommending it (probably latest at the time). I would've usually gone for the latest stable or longterm one.
It was interesting to note that multiple comments in the bugzilla thread mention the playback becoming silent with
implicit_fb=1. One comment even describes it like this:
Yep this is consistent with other users experience: implicit_fb=1 is a workaround for UMC204HD but not for UMC404HD
On UMC404HD , loading the module with implicit_fb=1 makes playback completely silent...
Maybe this is the same issue I had been facing with UMC202HD? Switching the profiles and devices back and forth in pavucontrol would solve this too? (By the way, I haven't had to do that yet in 5.19.0.) But why was it silent in the first place and why would meddling with profile and device selections in pavucontrol solve it? What makes it complicated is that the solution literally used to be switching from A to B and then back to A, rather than just A to B.
I've commented about these issues in the bugzilla thread itself. I'm sure the experts there could shed some light. I've also asked if anybody could please point me to any resource where I can understand what implicit fb is, what 'EP' in 'Open EP 0x8' is, etc. (you'll be surprised to see how less documented these things are; looking at the code of snd_usb_audio also doesn't help much since most of the time it's just about switching flags and sending some brief commands to devices -- stuff actually seem to happen elsewhere).