LinuxMusicians
So I have been using Linux for a long time but I have NEVER been able to play my guitar through Linux well. It is the one factor I cannot seem to fix. I had Line 6 devices which are terrible for Linux. I looked and got this Behringer UMC202HD which is compatible with Linux.
I need help getting this to work. What I am looking for:
Best DAW for Linux. Ardour is a lot more complicated then Reaper or Studio One. Honestly Audacity is the best so far but flaky.
Jack setup and config with the Behringer UMC202. A recent tutorial would be helpful.
Can we get a thread going to discuss best ways to play guitar and record on Linux? I saw youtube vids where people are playing guitar and it sounds amazing, but I have only ever been able to get a raw clean sound which sounds terrible.
Linuxmusician01 Established Member Posts: 1337 Joined: Mon Feb 23, 2015 2:38 pm Location: Holland Has thanked: 569 times Been thanked: 108 times
Re: Guitarix & Behringer UMC202HD
Post by Linuxmusician01 » Sat Mar 16, 2019 1:54 pm
omicronkappa278 wrote: [. ] Best DAW for Linux. Ardour is a lot more complicated then Reaper or Studio One. Honestly Audacity is the best so far but flaky.
I don’t think there is such a thing as the best DAW (for any OS). Depends very much on what you want. Audacity is no full blown DAW but very straight forward in it’s use. A DAW that can do more than that but is not complicated does not exist if you ask me. Then (community) support comes into play. Ableton Live and Bitwig appear the be the most used DAW’s today so community support will be good for those, I think. Qtractor (= Linux only) handles MIDI very well. It’s developer is active on this forum. I found Demonic Sweaters’ video’s on YouTube very handy for Qtractor (link).
omicronkappa278 wrote: Jack setup and config with the Behringer UMC202. A recent tutorial would be helpful.
Simply start Jack and you’re good to go (don’t forget to install pulseaudio-module-jack so PulseAudio plays nice w/ Jack). Use this command if your UMC202 is the second audio card (numbering starts at 0) on your computer:
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.
Read more from Nandakumar at nandakumar.org/blog/