Behringer UMC202HD choppy audio
mr-hollywood opened this issue · 25 comments
Many thanks for the awesome work on this project!!! FYI, I'm experiencing an issue with constant choppy sound using the UMC202HD USB device. Don't know if this is related to the issues with the Focusrites, but believe it's caused by the 5.1 kernel. I'm getting multiple USB "clock source 41 is not valid, cannot use" messages in dmesg. Regards!
@mr-hollywood Thanks for reporting. I tried latest release 1.5.0-b.1 (is that what you are using?) with Behringer UMC2 which I believe has same codec.
Audio was OK but I found a different problem. I made a last-minute change to kill pulseaudio while using Jamming apps, but that was a mistake because pulseaudio seems to be required for alsa mixer controls.
I'll post a revised image shortly.
I don't think this will fix choppy audio or clock source issue, but to revert the change, you can run the following command:
sudo sed -i '/^[^#].*\/usr\/bin\/pulseaudio --kill/s/^/#/g' /usr/local/bin/*start.sh
If that doesn't help, I'll need more info. Are you using Pi4? dmesg output? any other USB devices present? Is same issue present on both 1.5.0 and 1.4.0-b.2?
Jambox 1.5.0 uses a vanilla kernel configured for low-latency, so a kernel issue seems unlikely. 1.4.0-b.2 had a patched kernel with focusrite support but it's too painful to maintain the patches so I have stopped doing that.
Hi Kevin, I'm using a pair of RPI4b/4g for my testing...
The same sound issue is also present on 1.4.0-b2 and 1.2.0. The initial Jambox release doesn't see the UMC202HD at all. The issue affects all apps on the system and there are no other devices connected to the RPi. I applied the patch to 1.5.0-b1, but that didn't affect the chop.
I've tested the UMC202HD on Windows without any issues, but it does use a different ASIO driver. Here are the RPi kernel and user logs:
kern.log
user.log
Fyi, I'm trying to use the RPis as IEM receivers over Sonobus. Initial testing using the bcm2835 had just a little too much latency. I've tested using a Windows laptop with the UMC202HD and performance was great. I'm just hoping I can get the RPis working because they'd also offer control via a tablet or phone (and cost a lot less). You can get better idea of what I'm trying to do here:
https://sites.google.com/site/mrhollywoodmusic/behringer-xr18/sonobus-iem
Regards,
Should also mention that I get the same choppy sound when using the UMC202HD with the latest "2021-05-07-raspios-buster-armhf.img" with, or without updates...
@mr-hollywood I don't have a UMC-202HD so I can't test (codec is different then UM2).
Jambox 1.2 release used 5.4 kernel.
A few thoughts:
UMC202HD supports 192K, it sounds like maybe the default clock rate is being incorrectly set by the kernel.
see this commit for a different device with similar problem: raspberrypi/linux@71f39ba#diff-de67aab26780c75c96b69bd8c76a9e52c45ae0d282826fc047c01e4c244237f2
Try running Qasmixer (icon on desktop. select hw device) to see if there are any clock rate controls.
I don't know if UMC202HD has updateable firmware, there is no separate firmware updater, but perhaps installing UMC202HD on Windows with latest driver from Behringer website would update the firmware. Or, maybe if you set rate to 48Khz in Windows, the device will remember when used with linux.
Ubuntu kernel has different USB drivers for RPi, you could try that.
Good luck,
Kevin
@mr-hollywood It appears possible to change the kernel settings for snd_usb_audio:
https://www.kernel.org/doc/html/v5.10/sound/alsa-configuration.html#module-snd-usb-audio
I think any options would go in a new .conf file i.e. /etc/modprobe.d/snd_usb_audio.conf (then reboot).
The interesting option you might try is autoclock.
options snd_usb_audio autoclock=no
autoclock defaults to yes, which might be causing problems.
Hi Kevin, no joy with adding the autoclock option to /etc/modprobe.d/snd_usb_audio.conf. The UMC202HD doesn't seem to be firmware upgradable, and I can't tell if it retains any settings after being used in Windows. There are also no clock rate controls for the UMC202HD in Qasmixer.
Found the following link about a common issue with USB Dac interfaces needing some delay between the usb interface start and the playback, that generates the same "clock source 41" error code: https://bugzilla.kernel.org/show_bug.cgi?id=108961
There's a solution to the problem here, but don't know how that relates to the RPi:
https://guillaumeplayground.net/teac-ud-503-ud-501-snd-usb-audio-patch/
This also made me wonder whether the "delayed_register" option in "Module snd_usb_audio" could be used to accomplish the same thing???
@mr-hollywood I saw those posts, they are specific to a particular ITF codec chip used in a few Teac/Denon/Marantz players. But other devices have reported similar issues, You could compile your own module, but that could get complex. For a simpler way to try, there is a modprobe option "quirk_alias" which tells the snd_usb_audio module to map the USB device ID of your device to the device ID of the quirk you want to use. Challenge will be to get the syntax and device IDs right.
I would have thought the option should go in a modprobe .conf file.
However, this post shows it going at end of /boot/cmdline.txt
Perhaps either would work, but this link is fairly detailed so I would start by following it.
https://forums.raspberrypi.com/viewtopic.php?t=15872
also see: https://linuxmusicians.com/viewtopic.php?t=18046&start=30
Youd device I think is 1397:0507
A device with the quirk you referenced is: 154e:1003
So on cmdline.txt:
snd-usb-audio.quirk_alias=13970507:154e1002
or in /etc/modprobe.d/snd_usb_audio.conf:
options snd_udb_audio quirk_alias=13970507:154e1003
I think it may even be possible to apply to a running system:
sudo modprobe -v snd_usb_audio quirk_alias=13970507:154e1003
Any issue caused by linux snd_usb_audio module would likely be platform-independent. You could boot a PC to Ubuntu (i.e. live usb stick) and see if the issue persists there. or you could try ubuntu on raspberry pi (it has different USB hardware driver than raspberry pi OS).
One other thought. Not sure exactly what you mean by "choppy audio". Does /var/log/syslog show lots of XRuns during audio transfer?
Jambox on pi4 defaults to PERIOD=64, NPERIODS=3 except for JamTaba and JammerNetz. This is set in /etc/jackdrc.conf This is to keep latency as low as possible, and works for all USB interfaces I have tested. But maybe yours is an exception.
You could try setting i.e. PERIOD=256 to see if/how it changes the symptoms. Or run JamTaba (which has PERIOD=128) and click "listen" on a room if there is one in progress,
Other people have reported UMC202HD working under linux, although not sure if any were on RPi.
Edit: more thoughts:
The "alsa-info" command will create a file with a dump of all audio-related system info. "sudo apt install tree" first.
You might want to debug this in pure alsa to take jack audio out of the equation ("sudo systemctl stop jack" first). Is audio choppy when you use the "speaker-test" command ?
Those "quirk_alias" fixes are really cool, unfortunately I haven't found one that does the trick. The QUIRK_FLAG_CTL_MSG_DELAY_1M reduced the number of "clock source" errors in dmesg by about half, but that's all.
A better description for "choppy" would be that the sound toggles on and off at a constant rate of ~350ms. There's nothing in the system log with "Xrun" and PERIOD=256 had no effect.
I've been using Audacity, Sonobus and the alsamixer to test sound, and haven't paid much attention to Jack Audio. Haven't tried the "speaker-test" command yet.
I also tried the raspios-bullseye-arm64 OS with the same results, and I'll try the Ubuntu desktop tomorrow.
PS: I also tried another USB cable to avoid really embarrassing myself... :)
Cables should never be taken for granted. I once spent days tracking down what I thought was a software bug, but was really a marginal 3-foot ethernet cable.
Also Power supply. UMC 202HD is bus-powered. Swap your pi supply if you have a spare, or try a powered USB hub (although hub can introduce other problems. Also try USB3 vs USB2 ports on RPi.
You may see references to an option in /boot/config.txt to increase USB power, but that is now default setting so you can ignore it.
Shouldn't make a difference, but you could update the boot loader. check with "sudo rpi-eeprom-update", and update with "sudo raspi-config" under advanced -> bootloader -> latest
This guy has a UMC204HD working with RPi: https://www.youtube.com/watch?v=PrA4rtC0RYo
He walks through his config.
Also this post from someone using UMC404HD on RPi: https://sourceforge.net/p/llcon/discussion/hardware/thread/25f0f8bcb2
I always hate to blame the hardware (RPi or Behringer), but sometimes it really is. At some point you need to consider swapping one or the other.
Hi Kevin, I've got two RPi4b with 3A power supplies and one has an updated bootloader. I've seen those videos, and it's fairly basic stuff. I have a feeling there's something different about the 202.
Tried it on the RPi Ubuntu Desktop with much the same results (but only one clock error message). Same with the early versions of RasPiOS using the 4.19 kernel.
I did notice that when I change the sample rate in Sonobus, the speed of the "chop" changes accordingly. That's the only time I've seen it change. Have to think about that one...
Anyway, I'm going to step back a bit before I find myself locked in a padded room mumbling "clock source 41".
Thank you so much for all your help. It's been really appreciated!!! :)
George
Jack on jambox is set to 48k. If you set sonobus or any other app to anything else, it won't work.
I have see references that say the clock source 41 message is in some case innocuous.
In most cases, a freshly burned jambox SD card will work with no settings changes. It's preloaded with a sonobus settings file that should just work with the jambox jack setup.
Use alsa-info to generate an info file and post it here.
You might want to try changing NPERIODS from 3 to 6 or higher in /etc/jackdrc.conf.
Even more basic is to stop jack service and debug at the alsa level. Use speaker-test to send a tone. Use 48khz sampling (there may be other settings ie pulse audio which are set there). If audio is still bad, try other sampling rates to see if one works. You can test the other direction with arecord.
Changing the NPERIODS has no effect. Jack won't run when the UMC202HD device/card is selected. Here's a copy of the alsa-info file:
alsa-info.txt
@mr-hollywood
"Jack won't run when the UMC202HD device/card is selected."
what do you mean by this? alsa-info says jackd is running. what is output of systemctl status jack?
In jambox, jack.service starts jack with "-S" (shorts) argument, which should try to set device to 16 bits format.
But alsa-info shows USB stream set to "Format: S32_LE". Not sure if this could cause a problem.
What is output of: grep "ALSA.*format" /var/log/syslog
I would suggest stopping jack, then try to get it working just with alsa:
- stop jack and set the device:
sudo systemctl stop jack
DEVICE=`arecord -L | grep ^hw: | head -n1`
- try recording in 2 channels in 16-bit format for 10 seconds at 48 KHz sampling:
arecord --channels=2 --format=S16_LE --duration=10 --rate=48000 --device=$DEVICE test1.wav
copy to another computer to play it so you can verify that capture was working.
You can play file out with same options to verify playback:
play --channels=2 --format=S16_LE --duration=10 --rate=48000 --device=$DEVICE test1.wav
If you can't record/play a simple test file with alsa, you should get that working before going on to something more complex.
If these don't work, try format S32_LE or S24_LE.
The capture is good and plays normally on a Windows PC, but is "choppy" when played back on the RPi (arecord would only accept S32_LE).
The grep "ALSA.*format" /var/log/syslog only provided the following:
Dec 4 22:27:11 jambox jackdrc[384]: ALSA: final selected sample format for capture: 32bit integer little-endian
Dec 4 22:27:11 jambox jackdrc[384]: ALSA: final selected sample format for playback: 32bit integer little-endian
Here's the alsa-info following the tests:
alsa-info.txt
Edit: Not sure where the Jack problem came from, but I reloaded the OS image before running the above tests and Jack was running properly.
@mr-hollywood I'm wondering if inability to support S16LE for capture could be a problem.
Try running above tests with plug$DEVICE instead of $DEVICE. I believe the plughw device has ability to convert sample formats.
Try stopping jack, then running Audacity (it's installed on jambox image). I believe it can deal with formats,
set to ALSA, and set playback and capture devices to your hw device.
Then record something (this should work) and play it back.
You could also try looping capture back to playback through the plughw device (or just $DEVICE).
alsaloop -C plug$DEVICE -P plug$DEVICE -f S32_LE -r 48000 --channels 2
Audacity can record and playback in all three formats (S16/24/32_LE), but sometimes you need to set it twice to get sound. Chop is still present.
Here are the errors reported for the other commands:
arecord --channels=2 --format=S16_LE --duration=10 --rate=48000 --device=plug$DEVICE test3.wav
ALSA lib pcm.c:7699:(snd_pcm_slave_conf) missing field pcm
arecord: main:831: audio open error: Invalid argument
aplay --channels=2 --format=S16_LE --duration=10 --rate=48000 --device=plug$DEVICE test3.wav
ALSA lib pcm.c:7699:(snd_pcm_slave_conf) missing field pcm
aplay: main:831: audio open error: Invalid argument
alsaloop -C plug$DEVICE -P plug$DEVICE -f S32_LE -r 48000 --channels 2
LSA lib pcm.c:7699:(snd_pcm_slave_conf) missing field pcm
playback plug open error: Invalid argument
Loopback initialization failure.
alsaloop -C $DEVICE -P $DEVICE -f S32_LE -r 48000 --channels 2
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for 0
playback hw:0,0 open error: No such file or directory
Loopback initialization failure.
So capture is OK and chop is only present on playback? Is chop present on both L & R channels?
You could try speaker-test program to generate test tones. But since you got bad audio playing a confirmed good file, so I would not hold out much hope for that working.
This is the point at which I would really want to confirm that a different UMC202HD exhibits the same problem. Other people have reported that working with linux.
hypotheses:
- it's a linux kernel bug. to test, you could boot a PC to ubuntu live USB stick and see if you have same problem. But others have reported it working under linux.
- it's a bug with your UMC202HD. But to believe that, you have to believe your unit is bad in a way that only shows up under linux but it works under windows. not likely.
- it's a raspberry pi specific problem. But you had same problem with RPi ubuntu build, which uses standard kernel. So if this is the case, it would need to be a bug in usb audio code that is shared by ubuntu and raspberry pi OS but not used in x86 ubuntu. I don't think there is much of that.
- it's a problem with your specific setup. maybe something like bus-powering UMC202HD off of a RPi. I'd try it with a powered USB hub.
None of these seem likely. I guess my money is on #1, which would mean the reports of it working are wrong, or I misread them.
Yes, the "chop" is on both channels.
Just tried Ubuntu 20.04.3 live. There is a "glitch" that consistently shows up about every 20 seconds, but aside from that it works great. This doesn't happen in Windows and I don't have access to a Mac...
To me, a glitch every 20 seconds isn't "working great", more like "fails differently",
Could be a software (or hardware) issue that is timing related.
There are clearly reports of UMC204HD and UMC404HD working on a Raspberry Pi (even with Pi3), and they are quite similar, just more channels, If you can get access to another UMC202HD, you should see if you get same problem with a different unit. It would be quite odd to have a hardware problem that only shows up under windows, but you are at the point where any explanation is quite unlikely. You'd need some kind of marginal timing issue that works with Windows but not linux. Highly unlikely, but if it did happen it is exactly the kind of problem that would get past QA.
Exchanged the UMC202HD for a UMC204HD and it works perfectly. Looks like the UMC202HD just doesn't play nice with Linux...
Glad you got it working. My guess is that your UMC202HD was likely a bad unit - if they all did that it would have been reported. Doesn't matter now, though, and you'll probably find a use for the extra features on the 204.
I think I have the same issue described here; however I'm running on a PC. I'm also guessing it's a kernel bug, because no matter what I tried the choppy audio would not go away. I think I'll just buy a UMC404HD and keep the UMC202HD as a spare.
@chriswyatt You were running on a PC with linux? Ubuntu? which version?
FYI latest jambox version 1.5.0 has linux 5.15.10 kernel installed but not activated. It's not an official release yet but has been pretty solid for audio in my tests. There has been work done on the USB audio drivers, but I don't think any of the changes would affect UMC202HD.
If you want to try it, at the bottom of /boot/config.txt, there are sections for 4 kernels. Above the kernel sections you will see [all] above 5.10.74-llat kernel, and [none] above the others. To change, set [all] to none above 5.10.74-llat, and change [none] to [all] above 5.15.10-llat, then reboot.
@[mr-hollywood], i have buy last week the BEHRINGER UMC204HD and i have the same error (clock source 41 is not valid, cannot use) X86-64 : latest ARCHLINUX
Audio Stuttering every X seconds... (depending Samplerate) (this is not Xrun)
Can you try this :
-Unplug the USB cable
sudo modprobe -r snd_usb_audio
sudo modprobe snd_usb_audio implicit_fb=1
-Plug USB audio card and test (no reboot)
if it work : can you copy / paste
lsusb -v -d 1397:0507
i think we can upstream the bug to alsa project in kernel
Information that i have read to understand history
https://guillaumeplayground.net/teac-ud-503-ud-501-snd-usb-audio-patch/ (same error clock source 41)
https://nandakumar.org/blog/2022/02/umc202hd-linux.html