Upgrading Linux to Make UMC202HD Work Again

(Last updated on 2023-03-03.)

Summary: upgrading Linux from 5.15.13 to a newer version was required to make playback through Behringer U-PHORIA UMC202HD work again. Even after the upgrade, for Linux 5.19.0, 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 worked fine. On Linux 6.2.1, it works fine without any manual intervention.

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

It Works Fine

(Added on 2023-03-03.)

More than a month ago, a radio professional named Jamey Kirby emailed me saying that the device works fine for him with Linux 6.1.7. Only today could I test a newer kernel, and after upgrading from Linux 5.19.0 to Linux 6.2.1, I can confirm that UMC202HD playback works fine for me too, without any manual intervention. This continues to puzzle me, since the quirk was already included in 5.19.0. I guess something general related to USB audio was involved.

Here's the debug report (note that modprobe was needed only to check the debug messages, not to make it work):

5.19.0-051900-generic:

After modprobe -r snd_usb_audio and modprobe snd_usb_audio dyndbg==p, dmesg|grep -i implicit_fb=1 gives no output (because it's all implicit_fb=0).

6.2.1-060201-generic:

The same gives this output:

root@nandakumar-laptop:/home/nandakumar# dmesg|grep -i implicit_fb=1
[  132.329446] usb 3-4:   channels=2, rate=48000, format=S32_LE, period_bytes=9600, periods=4, implicit_fb=1
[  132.331005] usb 3-4:   channels=2, rate=48000, format=S32_LE, period_bytes=9600, periods=4, implicit_fb=1
...

Back to the conversation with Jamey, this was his first message (he's using Rasberry Pi while I'm on a usual PC):

Install the latest OS and firmware fixes the issue:

sudo rpi-update newest
sudo reboot

I also did this for good measure:

sudo rpi-eeprom-update -a
sudo reboot

Behringer 202HD, 204HD, and 404HD all play just fine after updates.

-- Jamey

I'm still not sure how firmware plays a role in this (especially since we are not talking about UMC202HD's firmware, which seems not user-upgradable as of now). However, the commands he used actually solve the issue because that results in an upgraded Linux.

Here's another mail from him which is also worth sharing:

Here is a little more on updating the Raspberry Pi. Using RPI-update, it will update the Linux kernel and the Eeprom to the latest tested release. If you use the option next, it will upgrade to the latest unofficial release (kernel 6.1.x in my case).

https://www.raspberrypi.com/documentation/computers/os.html#using-rpi-update

I don't have more details at the moment. I do use the Behringer on my Windows machines as its primary audio interface, and I have the drivers loaded. There was a time about three or four years ago when you could manually download and install the Behringer firmware. It has since been moved into the Windows driver package.

Although I have another Linux desktop, I have not tried the Behringer there. I only tested the Pi. But I can say for sure on my Pi4 B with kernel 6.1.x, playing audio works. Prior to the update, it did not.

You can share any part of my finding you wish. When I get a little extra time, I will try some other things. If I find anything noteworthy, I'll drop you an email.

-- Jamey

The last paragraph was his response to my seeking permission to share his experience. Later he shared this link, which is also helpful: https://github.com/raspberrypi/rpi-update.

Thank you, Jamey.