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
>
