Upgrading Linux to Make UMC202HD Work Again

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 dmesg.

System: Linux 5.15.13, Ubuntu 22.04.1 LTS, KDE Plasma Desktop, PulseAudio (on PipeWire 0.3.59, according to pactl info).

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 flags 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 dmesg with 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

With modprobe snd_usb_audio dyndbg==p implicit_fb=1, it reports implicit_fb=1 after 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.

Sidenote

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.

It Continues

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).