On Thu, Jan 13, 2022 at 08:07:49PM +0530, Nandakumar Edamana wrote:
Trying to make my Behringer UMC202HD audio interface work with GNU/Linux. While doing so, I managed to make a warning disappear by editing a file in the kernel source. The main issue I'm having with the interface isn't gone, and I am not sure whether to bother you people with that now. However I'd like to read your comments on the edit I made regarding the warning.
Details:
- Product: 1397:0507 BEHRINGER International GmbH UMC202HD 192k
- dmesg warning: clock source 41 is not valid, cannot use
- kernel: linux-5.15.13
- Edit that made the warning disappear:
$ 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)) {
Yes, I was just adding the ID of UMC202HD to an existing workaround. I'm not sure if the device's clock should actually be accepted (but I think so because the retry works, right?), or if two seconds is the right delay for UMC202HD.
The real issue I'm having with this device is related to the periodic stuttering/pops while playback (recording is okay).
Hi Nandakumar,
You made the dmesg warning go away, but that didn't necessarily solve the underlying issue. May I ask that you post the "lsusb -v -d 1397:0507" ?
I may ask you to activate dyndbg for the snd-usb-audio module next.
I remember having read that UMC20x is well-supported in Linux. Maybe now they're using a different firmware version or something?
Seems to be a different revision indeed, but don't worry, most of the time these bugs are fixable.
If you are interested, here is a list of things I've already tried:
- Different ports, including USB 2.0, and disabling xHCI using `setpci`
- Disconnecting other USB devices
- Disabling wireless
- Making sure speech-dispatcher isn't running
- Old and new GNU/Linux distros on different computers
- Switching sound servers (PulseAudio and JACK) and direct ALSA
- Different sampling rates, buffer sizes, etc.
- Lower volume levels
- Making sure there are no xruns
- tsched=0 and 1 for module-udev-detect (pulse)
- realtime-scheduling, high-priority, and nice-level (pulse)
- Choosing Performance mode for CPU Governer and disabling Intel Boost
(as recommended by Ubuntu Studio dashboard)
- lowlatency kernel
- A recent kernel (v5.15.13) built from source with oldconfig
- Clock source workaround in sound/usb/clock.c
- Quirk entries in sound/usb/implicit.c (I won't claim I did it right)
Again, I'd like to hear your comments on the clock detection workaround first, since that's the only thing I seem to have solved with all these hours spent (except for learning a lot, of course). But if you have time, please consider the second (main) issue also. Maybe I'm posting this in the wrong place; if so, please let me know where to repost it (official forum or a kernel mailing list).
alsa-devel is the place where finished contributions land, but it's also a place to ask for lower-level help in ALSA development. Don't worry, you are in the right place.
Thank you,
-- Nandakumar Edamana https://nandakumar.org
GPG Key: https://nandakumar.org/contact/gpgkey.asc GPG Key Fingerprint: BA6B 8FDE 644F F861 B638 3E2F 45D6 05FC 646A F75D