Behringer UMC204HD HiFi "Default" profile crackling audio

[acepukas]

Since the recent update to 1.2.7.2, the Behringer UMC204HD "Default" profile has crackling audio through "Line A" and "Line B" ports. Switching to the "Direct" profile allows for clean audio but it's output over 4 speakers (front left and right, rear left and right). Not really sure how to trouble shoot this.

[perexg]

If you remove (comment out) two last added lines (buffer_time, period_time) in fb69d0f , do things work better ?

[acepukas]

It sounds better but not clear still. After the adjustment the audio sounds like it's being put through a ring modulation filter. Not sure how else to describe it.

[perexg]

One piece of UCM204HD box landed on my table, but I cannot confirm that behavior. The stereo playback (split to "Line A" and "Line B") is clear with both pulseaudio and pipewire.

Which sound server do you use ?

Could you copy this to ~/.asoundrc:

pcm.umc204hd_stereo_out {
	@args {
		0 CARD
		1 DEV
		2 CHN0
		CARD.type string
		DEV.type integer
		CHN0.type integer
		3 CHN1
		CHN1.type integer
	}
	ipc_key 6678293
	type dshare
	slave {
		pcm {
			type hw
			card $CARD
			device $DEV
			chmap [
				FL
				FR
				FL
				FR
			]
		}
		channels 4
		period_time 10000
		buffer_time 500000
	}
	bindings.0 $CHN0
	bindings.1 $CHN1
}

and run

speaker-test -D umc204hd_stereo_out:U192k,0,1 -t sine -b 100000

is the sound clear ?

EDIT: Note you must suspend the sound server before the speaker-test command.

[acepukas]

I'm currently using pulseaudio. I ran the speaker-test as specified but the audio is still crackling. I made sure to suspend pulseaudio first and that ~/.asoundrc contained only the snippet you gave. Is there anything else I might need to disable or configure for the test?

[perexg]

The right speaker-test command should be: speaker-test -D umc204hd_stereo_out:U192k,0,0,1 -t sine -b 100000 -c 2

Could you attach output from:

1. sudo lsusb -d 1397:0508 -vvv
2. alsa-info.sh --no-upload

[acepukas]

Ok, I ran the updated speaker-test command with the audio bouncing from left to right speaker and got pretty much the same results as before. Crackly audio.

command output:

lsub_ouput.txt

alsa-info.txt

[perexg]

I don't see a suspect difference from my setup. The USB device identifier is similar.

Could you show output from cat /proc/asound/card3/pcm0p/sub0/* for "Default" and "Direct" profiles ?

[acepukas]

Sure thing.

Direct:

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 4
rate: 44100 (44100/1)
period_size: 1102
buffer_size: 4408
card: 3
device: 0
subdevice: 0
stream: PLAYBACK
id: USB Audio
name: USB Audio
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
state: RUNNING
owner_pid   : 148492
trigger_time: 256345.235089193
tstamp      : 256375.335612376
delay       : 4452
avail       : 441
avail_max   : 441
-----
hw_ptr      : 1327255
appl_ptr    : 1331222
tstamp_mode: ENABLE
period_step: 1
avail_min: 1102
start_threshold: 18446744073709551615
stop_threshold: 4962966789362286592
silence_threshold: 0
silence_size: 0
boundary: 4962966789362286592

Default:

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 4
rate: 48000 (48000/1)
period_size: 480
buffer_size: 24000
card: 3
device: 0
subdevice: 0
stream: PLAYBACK
id: USB Audio
name: USB Audio
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
state: RUNNING
owner_pid   : 148492
trigger_time: 256382.524352280
tstamp      : 256392.705603800
delay       : -449412
avail       : 473844
avail_max   : 473844
-----
hw_ptr      : 449844
appl_ptr    : 0
tstamp_mode: ENABLE
period_step: 1
avail_min: 480
start_threshold: 1
stop_threshold: 6755399441055744000
silence_threshold: 0
silence_size: 6755399441055744000
boundary: 6755399441055744000

[perexg]

This ~/.asoundrc configuration should simulate the direct setup for speaker-test -D umc204hd_stereo_out:U192k,0,0,1 -F S32_LE -t sine -b 100000 -c 2 command:

pcm.umc204hd_stereo_out {
	@args {
		0 CARD
		1 DEV
		2 CHN0
		CARD.type string
		DEV.type integer
		CHN0.type integer
		3 CHN1
		CHN1.type integer
	}
	ipc_key 6678297
	type dshare
	slave {
		pcm {
			type hw
			card $CARD
			device $DEV
			chmap [
				FL
				FR
				FL
				FR
			]
		}
		channels 4
		period_size 1102
		buffer_size 4408
		format S32_LE
	}
	bindings.0 $CHN0
	bindings.1 $CHN1
}

[acepukas]

This time around it was a nice clear sine wave tone. I suspect the format setting has something to do with it? I noticed they were different between the Direct and Default profiles.

[perexg]

Could you try to add only format S32_LE line (bellow buffer_time line) to the original UCM configuration file - fb69d0f ?

[perexg]

... or try the commit 3753c50 with the format change above ..

[acepukas]

I tried the 3753c50 commit but same as before, crackly audio. When I made the changes I rebooted my system. Not sure if that is necessary or if I just have to restart pulseaudio?

[perexg]

In the split.conf configuration file, try to also change:

   period_time "${evali:$__period_time}"
   buffer_time "${evali:$__buffer_time}"

to

   period_size 1102
   buffer_size 4408

[acepukas]

That did the trick. Clear audio on "Line A" and "Line B".

[perexg]

But it does not explain the correct behavior on my test equipment with all buffer and period sizes and both formats.

Unfortunately, I'm not willing to hardcode those values to the configuration until the culprit is not determined.

[acepukas]

For sure. Understandable. Very odd that your UMC204HD is fine with the original config but mine is not. Makes me think there's a difference in hardware. If that's the case and Behringer didn't tell anyone, that would be a big misstep. Mine was purchased fairly recently.

[brndd]

I have this same device, but it works fine for me on 1.2.7.2 on Fedora 36. Short of a randomly defective device, could it be something else in your hardware? Maybe you could try the device on a different computer with the same version of alsa-lib?

[acepukas]

@brndd I'll test with other hardware. I don't understand why my device functioned without issue prior to 1.2.7.2 though. Doesn't that preclude a hardware issue?

[brndd]

I don't know enough about the topic to really have any genuinely useful input, but since it's a USB device and the relevant change seems to be to various latency-related things, then maybe it could be down to the USB controller. I'm not saying there's an outright issue with your hardware, but it could be possible that the new default settings aren't safe for all hardware configurations.

[XANi]

I had it working perfectly (aside from not having input split into 2 mono, and output being 4.0 instead of 2+2, but I fixed that on pulseaudio side) on 1.2.4 (Debian Stable). Upgrade to current(1.2.8) in Debian Testing caused:

• "HiFI" profile produces half a second latency that makes it basically unusuable

• "Direct" profile produces crackling and wrong sample rate (which is bizzare)

I had purchased mine 2022-10 so quite recent too, whatever was done in fb69d0f needs to be reverted, splitting with 500ms buffer is horrid for video games or anything interactive.

[acepukas]

Just want to add to the thread that I didn't test the UMC204HD with another machine (lacking an alternative system to test with) but I did switch over to using pipewire and since then everything is working great. I'm not suggesting that is the solution, only that pipewire seems to provides a configuration that works well out of the box. That doesn't mean that there isn't a hardware issue but somehow there is a way to make it work even with some kind of hardware discrepancy.

[XANi]

I replaced motherboard and CPU and it continued working. I have mine connected directly to motherboard. I'm up to some testing if it is helpful. Previous one was some old DDR3 system, current one is zen4 CPU on X670E chipset

Pipewire doesn't work at all for me for some reason (process doesn't even accept commands and any client times out), but that's not related to interface as I have same thing on builtin sound card

[brndd]

PipeWire uses this same UCM configuration, so it sounds to me that the issue might only occur on PulseAudio systems.

[stephematician]

@perexg The UMC202HD-HiFi should also use S32_LE rather than the default (S16_LE).