Behringer UMC202HD issues and a partial solution

[Geraldo Nascimento]

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
>