Making Behringer UMC202HD Work With Linux

Update on 2023-01-16: upgrading Linux from 5.15.13 to a newer version was required to make playback through UMC202HD work again. Read the new post for the details.

I recently purchased a Behringer U-PHORIA UMC202HD audio interface, and immediately noticed an issue while trying it out on my GNU/Linux system. The recording was fine, but the computer playback was not. It was choppy or stuttering (breaking every other second). Direct monitoring was working well, so I knew it was a software issue. I tried out everything I knew, and everything I found on the Internet. But turned out the issue was deep inside the kernel. It isn't solved yet, but it is very easy to work around.

This particular problem helped me learn more about Linux audio and audio in general. But most importantly, it made me edit the kernel code, build it, and run the system on a self-built kernel for the first time (don't worry, you are not required to do the same just to get this audio interface working).

Let me also thank Geraldo Nascimento from the alsa-devel mailing list for suggesting the workaround that I'm currently using.

The Workaround

If you are here after facing the exact same issue with the exact same model, and you don't want to read any more (but I recommend you do), here is the solution: just modprobe snd_usb_audio with the option implicit_fb=1.

In practice, this is how you do it:

Disconnect all USB audio devices
modprobe -r snd_usb_audio
modprobe snd_usb_audio implicit_fb=1
Connect the USB audio device in question
Try playing through the device; switch the audio device selection in your audio mixer or settings (say pavucontrol, the Pulse Audio Volume Control) back and forth if there was no sound at all

Should There Be Such an Issue?

No. Behringer U-PHORIA UMC202HD (and most other USB audio interfaces) is said to be class-compliant. This means the device should work plug-and-play on any modern OS. But sometimes device makers break the specs, sometimes OS-side developers don't implement them right. Things break. Windows users usually don't observe this because they always install vendor-provided drivers, which will make up for any odd characteristic in the device part. But as long as you buy a class-compliant device, there is a good chance that you can make it work on GNU/Linux by tweaking some parameter.

I bought this model reading that it worked plug-and-play on GNU/Linux. Apparently the copy I got is a different revision. Back then, there was no thread I could find online related to the issue I was having, but it seems more people are reporting similar issues regarding this model. A comment in a Reddit thread even links to the alsa-devel thread I started. The OP has updated the post saying that the solution didn't work for them and they've purchased UMC204HD, which worked well. There isn't enough info on the thread regarding what they've tried yet, making further comments impossible. They've stated that the device stuttered even on Windows. If they were using the official driver, it could be a buffer size issue, or a hardware issue in worst case. UMC202HD seems to be a risky pick, but I believe one should be ready to get one's hands dirty even when going for a different vendor and model, when it comes to computer-connected devices.

General Solutions

If you didn't come here for UMC202HD, there's a lot to try out first:

Different USB ports, USB 2.0 ports, no hubs, or a powered hub
Disabling WiFi and similar
Setting different sampling rates and different buffer sizes (can be done with Audacity, qjackctl, or commands like aplay)
A different and up-to-date OS version
An outdated OS version to see if this is a regression issue
Different resampling methods in your audio server

And some GNU/Linux-specific things:

Try out everything in pavucontrol and alsamixer
Make sure speech-dispatcher isn't running (see https://bugs.launchpad.net/ubuntu/+source/speech-dispatcher/+bug/1739310)
Enable/disable realtime capabilities for servers like Jack
Try using ALSA directly with aplay
Use a different desktop environment (Xfce, GNOME, KDE, etc.)
Use a different distro (I suggest Ubuntu Studio, which has a lot of audio-related packages and a comprehensive dashboard where you can try out several parameters including CPU Scaling Governor)
Try a different audio server (PulseAudio, Jack, etc.)
Install and use a low-latency kernel (usually the kernel variant you are using is generic)

Buffer size is an important thing that you usually don't hear until you try to use an audio interface. I recommend looking it up, even though it doesn't solve the issue.

Kernel Adventures

Since it's been at least a month and a half, I've forgotten the exact sequence of events. The following is what I could come up with after checking the quick journals I've kept.

After trying out all kinds of configurations and different distros (old and new), I decided to have some fun with the source. I spent some time editing and recompiling alsa-utils, just to learn how things work. Then moved on to the kernel.

The Non-solution

I believe seeing the following message in dmesg output was the starting point of the kernel experiments:

usb 3-1.1: clock source 41 is not valid, cannot use

A quick search yielded some kernel patches that introduced me to the world of kernel "quirks", which add device-specific workarounds to the kernel (waiting for some seconds after sending a command, setting a specific flag, etc.). I downloaded the kernel source and started exploring. Thanks to the friendly build and install system, I was able to add the device ID of UMC202HD to an existing quirk, compile it, and load. Here's the patch:

$ diff -u sound/usb/clock.c.orig sound/usb/clock.c
--- sound/usb/clock.c.orig    2022-01-13 08:14:49.555281286 +0530
+++ sound/usb/clock.c    2022-01-13 08:18:38.004618792 +0530
@@ -180,7 +180,11 @@
      * Sample rate changes takes more than 2 seconds for this device. Clock
      * validity request returns false during that period.
      */
-    if (chip->usb_id == USB_ID(0x07fd, 0x0004)) {
+    if (chip->usb_id == USB_ID(0x07fd, 0x0004) ||
+        /* Trying the same for BEHRINGER International GmbH UMC202HD 192k */
+        chip->usb_id == USB_ID(0x1397, 0x0507)
+        )
+    {
         count = 0;

         while ((!ret) && (count < 50)) {

It got rid of the dmesg warning, but the audio was still choppy. Also, I am still not sure if that patch should be applied.

The Near-solution and My Stupidity

However, cat /proc/asound/card1/stream0 introduced me to another term, Implicit Feedback, which was set to false. There is surprisingly little information about this topic on the Web (I did learn a bit, but forgot already). Anyway, being desperate, I walked through the kernel source and found another set of quirks that are dedicated to implicit feedback. There were different kinds of them, and I applied each of them in vain.

This was when I started a discussion on the alsa-devel mailing list (https://lore.kernel.org/alsa-devel/YeB2zEnPlwVEKbTI@geday/T/), and got immediate response from Geraldo.

Geraldo suggested me to use modprobe snd_usb_audio implicit_fb=1, and it worked.

He later added that the following line I had added (to sound/usb/implicit.c) should've been enough:

IMPLICIT_FB_GENERIC_DEV(0x1397, 0x0507),

The exchange (including some patches) continued for a while, until I noticed my changes were no longer being applied in reality (the newly built files were not the ones that were being loaded). I had been acting like a pro kernel dev while actually being a failure in loading modifications!

I'm sure I did load the changes at least once, because the clock patch got rid of the warning. That means only the recent changes were left inactive.

Then I got busy and there was no further progress. I'd like to try out that patch once again, and I'll update this post when I do. If it succeeds, another thing to make sure is the quirk doesn't cause trouble for anybody who is already using UMC202HD (probably an older revision) without any issues on GNU/Linux.

Current Situation

Now I run modprobe snd_usb_audio implicit_fb=1 after each startup. Not bothering to apply it permanently because I seldom shut down and there is a chance I'll miss the same issue if I use more devices.

Everything works fine, except I have to switch a couple of times between the device selection in pavucontrol before UMC202HD starts sounding.

If anybody is wondering what combinations work for UMC202HD, a buffer size of 512 and a sampling rate of 48kHz works fine, and I remember higher and lower values also working fine.