Bug 215934

Summary: Behringer UMC 404 HD : clock source 41 is not valid and audio stuttering (confirmed for bcdDevice = 1.35)
Product: Drivers Reporter: Luca Russel (luca0820+kernel)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: RESOLVED CODE_FIX    
Severity: blocking CC: 2xx04, bluzee, dpenner1.online, GooseYArd, kinnunen.jussi, leo, mazurkin, meneerjansen00, nandakumar, nielszweistein, nyandarknessgirl, sergey.wild.man, tiwai, untruclong.durabombarder
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.15-v7l+, 5.8, 4.18 on both x86_64 and arm64 Subsystem:
Regression: No Bisected commit-id:
Attachments: Alsa info from older model that is working without issue.
alsa-info output
output of alsa-info --no-upload
Bheringer UMC 404 HD bcdDevice=1.35 - LSUSB verbose - confirmed audio stuttering
Bheringer UMC 404 HD bcdDevice=1.35 - alsa-info - confirmed audio stuttering
output of 'lsusb -v'
Behringer UMC 204 HD bcdDevice=1.35 - alsa-info.sh - stuttering
lsusb -v for 1.12 device
Test fix for clock refecounting
Test fix for clock refecounting (v2)
Test fix for clock refecounting (v3)
Another test fix
Another test fix (revised)
A workaround patch for interface reset at clock change
Quirk table entries for Behringer devices
Output of alsa-info --no-upload for UMC202HD
Fix patch for UMC202HD

Description Luca Russel 2022-05-02 21:52:48 UTC
I have tested the Behringer UMC 404 HD usb audio device (https://www.behringer.com/product.html?modelCode=P0BK1)
from:
- Raspberry Pi 4 
with Moode Audio on Kernel 5.15-v7l+ 
- Dell XPS with Ubuntu 20.04 on kernel 5.8.

When the device is connected via USB (both 2.0 and 3.0 ports), I see 
"Clock Source 41 not valid" in syslog and during playback the audio starts and stop continually, it does stuttering.
I also verified that this problem appears with recent version (bcdDevice=1.35) while  does not occur with older firmware (bcdDevice<=1.12).

Anyway, I rebuilt the kernel patching the snd_usb_audio by adding a delay after commands (following the same quirks done on other interfaces for invalid clock source , like Teac for instance - see Bug 108961 – Teac UD-503: clock source 41 is not valid).

With the new patched kernel module, the error on invalid clock source 41 disappeared, but the audio stuttering is still there.

Just for the record, I experimented a bit with the current quirks available:

QUIRK_FLAG_GET_SAMPLE_RATE
QUIRK_FLAG_ALIGN_TRANSFER
QUIRK_FLAG_TX_LENGTH
QUIRK_FLAG_PLAYBACK_FIRST
QUIRK_FLAG_SKIP_CLOCK_SELECTOR
QUIRK_FLAG_IGNORE_CLOCK_SOURCE
QUIRK_FLAG_ITF_USB_DSD_DAC
QUIRK_FLAG_CTL_MSG_DELAY
QUIRK_FLAG_IFACE_DELAY
QUIRK_FLAG_VALIDATE_RATES
QUIRK_FLAG_SET_IFACE_FIRST

with no success.
Any pointers/directions on how to solve this issue?
I can do some debugging and test possible patches, but I need support to help.
Comment 1 Luca Russel 2022-05-02 22:13:30 UTC
I forgot to mention that I also tried implicit_fb=1 option when loading snd_usb_audio module. In this case the "clock source 41 not valid" message does not show anymore
but audio is completely silent (no playback at all).
Comment 2 Luca Russel 2022-05-03 18:27:58 UTC
Just tested also on 4.18 and the behaviour is the same: (on both x86_64 and arm64)

"clock source 41 not valid" shows up in the syslog and audio stuttering.
Comment 3 Ron L 2022-05-05 17:25:20 UTC
I can confirm that the older model UMC404HD with bcdDevice= 1.12 do work perfectly as a Class Compliant device.  It seems Behringer has changed something.
Comment 4 Meneer Jansen 2022-05-06 08:31:21 UTC
I can also confirm that the bcdDevice= 1.12 revision works without flaws.
Comment 5 Rero 2022-05-06 16:59:01 UTC
I also confirm this bug.
BcdDevice= 1.35

Ubuntu 22.04
Kernel : 5.15.0-27-generic #28-Ubuntu SMP Thu Apr 14 04:55:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Comment 6 Luca Russel 2022-05-07 09:29:13 UTC
(In reply to Ron L from comment #3)
> I can confirm that the older model UMC404HD with bcdDevice= 1.12 do work
> perfectly as a Class Compliant device.  It seems Behringer has changed
> something.

Yes , they have changed something that does not play nice with snd_usb_audio but
the device is still a Class 2 compliant device since it works without flaws in
both Mac OS X and Windows operating systems.

I also have found this that could be, even if lightly, related:
https://bugzilla.kernel.org/show_bug.cgi?id=204631

As I will have more time I will continue to report results of my investigations.
Comment 7 Takashi Iwai 2022-05-10 16:25:07 UTC
Could you upload alsa-info.sh outputs on working and non-working cases?
Run the script with --no-upload option and attach the outputs to Bugzilla.
Comment 8 Ron L 2022-05-10 22:16:28 UTC
Created attachment 300925 [details]
Alsa info from older model that is working without issue.
Comment 9 Rero 2022-05-10 23:27:02 UTC
Created attachment 300926 [details]
alsa-info output

alsa-info.sh output form my config :
EMU 1820m sound card
NVIDIA HDMI
Behringer UMC 404 HD
Comment 10 Meneer Jansen 2022-05-11 08:53:27 UTC
@Takashi Iwai: No problem. The is the output of the command 'alsa-info --no-upload'is in the attachment. I have a working Behringer 404 with bcdDevice= 1.12.
Comment 11 Meneer Jansen 2022-05-11 08:56:29 UTC
Created attachment 300931 [details]
output of alsa-info --no-upload

Sorry for my previous post. Here actually is the attachment for a Behringer 404 with bcdDevice= 1.12.
Comment 12 Takashi Iwai 2022-05-11 12:35:42 UTC
Unfortunately some outputs don't contain the lsusb contents (likely due to the old version of alsa-info.sh shipped).

Could you guys give the lsusb -v output for the corresponding device for bcdDevice=1.12 case?
Comment 13 Meneer Jansen 2022-05-11 12:44:29 UTC
Output of 'lsusb' for a Behringer 404 with bcdDevice= 1.12:

Bus 001 Device 006: ID 1397:0509 BEHRINGER International GmbH
Comment 14 Luca Russel 2022-05-11 12:59:46 UTC
Created attachment 300933 [details]
Bheringer UMC 404 HD bcdDevice=1.35 - LSUSB verbose - confirmed audio stuttering
Comment 15 Luca Russel 2022-05-11 13:02:25 UTC
Created attachment 300934 [details]
Bheringer UMC 404 HD bcdDevice=1.35 - alsa-info - confirmed audio stuttering

These are my outputs for Behringer UMC404HD bcdDevice=1.35 (non working case with audio stuttering ) with following commands: 

# attached in this comment
alsa-info --with-aplay --with-amixer --with-alsactl --with-configs --with-devices --with-dmesg --with-packages --no-upload

# attached in previous one
lsusb -v 

@Maneer Jansen: I think that it is missing verbose mode (-v) that is needed to make a detailed comparison.
Comment 16 Meneer Jansen 2022-05-11 13:30:52 UTC
Created attachment 300935 [details]
output of 'lsusb -v'

Attached is the output of 'lsusb -v'. :)
Comment 17 Jussi Kinnunen 2022-05-11 14:08:04 UTC
Created attachment 300936 [details]
Behringer UMC 204 HD bcdDevice=1.35 - alsa-info.sh - stuttering

I have device Behringer UMC 204 HD with bcdDevice=1.35, experiencing stuttering running kernel version 5.15.36_1. implicit_fb=1 also mutes audio fwiw.
Comment 18 Ron L 2022-05-11 18:10:08 UTC
Created attachment 300937 [details]
lsusb -v for 1.12 device
Comment 19 Takashi Iwai 2022-05-12 05:53:27 UTC
Thanks.  It looks like that the description changes significantly between those versions.

In anyway, a part of the problem (at least the invalid clock source as the original report mentioned) must be the multiple references on the same clock source from different interfaces.  Could you try the patch below?
Comment 20 Takashi Iwai 2022-05-12 05:54:05 UTC
Created attachment 300938 [details]
Test fix for clock refecounting
Comment 21 Luca Russel 2022-05-12 06:57:18 UTC
(In reply to Takashi Iwai from comment #19)
> Thanks.  It looks like that the description changes significantly between
> those versions.
> 
> In anyway, a part of the problem (at least the invalid clock source as the
> original report mentioned) must be the multiple references on the same clock
> source from different interfaces.  Could you try the patch below?

Thank you Takashi, I will try the patch asap.

Just an information: is there a specific kernel version I should use?
Comment 22 Takashi Iwai 2022-05-12 07:46:51 UTC
The best would be 5.18-rc6, but the latest 5.17.x stable would be fine, too.
For older releases, I'm not sure.  If it can be applied cleanly, it's worth to try, though.

BTW, there was a bug in the previous patch.  The fixed one is attached below.
Comment 23 Takashi Iwai 2022-05-12 07:47:33 UTC
Created attachment 300942 [details]
Test fix for clock refecounting (v2)
Comment 24 Luca Russel 2022-05-12 08:12:55 UTC
(In reply to Takashi Iwai from comment #22)
> The best would be 5.18-rc6, but the latest 5.17.x stable would be fine, too.
> For older releases, I'm not sure.  If it can be applied cleanly, it's worth
> to try, though.
> 
> BTW, there was a bug in the previous patch.  The fixed one is attached below.

Thank you Takashi, all clear. 
I will try the patch in the afternoon and I will report here the results.
Comment 25 Takashi Iwai 2022-05-12 09:16:01 UTC
I revised the patch again, now v3.
Comment 26 Takashi Iwai 2022-05-12 09:16:19 UTC
Created attachment 300944 [details]
Test fix for clock refecounting (v3)
Comment 27 Luca Russel 2022-05-12 17:19:34 UTC
Thank you Takashi.

I've tested the patch on 5.17, it is applied cleanly (all hunks succeeded) and
as you were supposing the "clock source 41" error is not reported anymore.

It is strange however that adding the delay using:
QUIRK_FLAG_CTL_MSG_DELAY
QUIRK_FLAG_IFACE_DELAY
has the same effect without requiring the ref_counting.
Do you explain this behaviour?

The sad part is that audio stuttering is still present even if the kernel 
does not complain for the clock source.

Any idea ?
Comment 28 Takashi Iwai 2022-05-13 10:23:11 UTC
(In reply to Luca Russel from comment #27)
> Thank you Takashi.
> 
> I've tested the patch on 5.17, it is applied cleanly (all hunks succeeded)
> and
> as you were supposing the "clock source 41" error is not reported anymore.
> 
> It is strange however that adding the delay using:
> QUIRK_FLAG_CTL_MSG_DELAY
> QUIRK_FLAG_IFACE_DELAY
> has the same effect without requiring the ref_counting.
> Do you explain this behaviour?

Apparently the clock source error comes from some unstable response of the firmware of Behringer device, and adding delays seem helping for that.  OTOH, my patch tries to reduce the unnecessary inquiry and setup of the clock when it's shared with multiple endpoints, hence it reached to the same end effect.  So far, so good.

> The sad part is that audio stuttering is still present even if the kernel 
> does not complain for the clock source.
 
So the stuttering has nothing to do with the shared clock issue.  It's something else, and currently I have no idea yet.  You've tested all quirk bits and nothing helped with respect to the stuttering bug, right?
Comment 29 Luca Russel 2022-05-13 16:42:49 UTC
I see. It is also strange that the implicit_fb mode make playback completely silent on 1.35 and works flawlessly in 1.12. 

> So the stuttering has nothing to do with the shared clock issue.  It's
> something 
> else, and currently I have no idea yet.  You've tested all quirk bits and
> nothing 
> helped with respect to the stuttering bug, right?

Yes right. 

I tried these ones on both architectures:

QUIRK_FLAG_ALIGN_TRANSFER

QUIRK_FLAG_TX_LENGTH

QUIRK_FLAG_PLAYBACK_FIRST

QUIRK_FLAG_CTL_MSG_DELAY
QUIRK_FLAG_IFACE_DELAY

QUIRK_FLAG_VALIDATE_RATES

QUIRK_FLAG_SET_IFACE_FIRST

but with no success.

I have not yet tried low latency kernel variant. 
Do you think it could make a difference?
Comment 30 Takashi Iwai 2022-05-16 10:20:39 UTC
Another thing you can try to set lowlatency=0 option for snd-usb-audio.
I forgot to add a quirk bit for controlling this, and it's changed only via this option.
Comment 31 Luca Russel 2022-05-16 11:27:12 UTC
(In reply to Takashi Iwai from comment #30)
> Another thing you can try to set lowlatency=0 option for snd-usb-audio.
> I forgot to add a quirk bit for controlling this, and it's changed only via
> this option.

Same result. Audio stuttering.

I have enabled kernel dyndbg, these are the outputs, hoping they are useful:

At modprobe with interface plugged in:
[  566.185667] usb 1-1.1: 1:1: found sync_ep=0x84, iface=1, alt=1, implicit_fb=0
[  566.185699] usb 1-1.1: 1:1: add audio endpoint 0x8
[  566.185773] usb 1-1.1: Creating new data endpoint #8
[  566.185798] usb 1-1.1: Creating new sync endpoint #84
[  566.186063] usb 1-1.1: 1:1 Set sample rate 192000, clock 40
[  566.192626] usb 1-1.1: 2:1: add audio endpoint 0x88
[  566.192712] usb 1-1.1: Creating new data endpoint #88
[  566.192941] usb 1-1.1: 2:1 Set sample rate 192000, clock 40
[  566.195880] usb 1-1.1: [10] FU [PCM Playback Switch] ch = 4, val = 0/1/1
[  566.195917] usb 1-1.1: [10] FU [PCM Playback Switch] ch = 1, val = 0/1/1
[  566.197799] usb 1-1.1: [10] FU [PCM Playback Volume] ch = 4, val = -32512/0/256
[  566.199626] usb 1-1.1: [10] FU [PCM Playback Volume] ch = 1, val = -32512/0/256
[  566.199917] usb 1-1.1: [11] FU [Mic Capture Switch] ch = 4, val = 0/1/1
[  566.199946] usb 1-1.1: [11] FU [Mic Capture Switch] ch = 1, val = 0/1/1
[  566.201664] usb 1-1.1: [11] FU [Mic Capture Volume] ch = 4, val = -32512/0/256
[  566.203373] usb 1-1.1: [11] FU [Mic Capture Volume] ch = 1, val = -32512/0/256
[  566.206059] usbcore: registered new interface driver snd-usb-audio

at playback start with speaker-test:
[  662.822766] usb 1-1.1: Open EP 0x8, iface=1:1, idx=0
[  662.822785] usb 1-1.1:   channels=4, rate=48000, format=S32_LE, 
               period_bytes=384000, periods=4, implicit_fb=0
[  662.822800] usb 1-1.1: Open EP 0x84, iface=1:1, idx=1
[  662.822814] usb 1-1.1:   channels=4, rate=48000, format=S32_LE, 
               period_bytes=384000, periods=4, implicit_fb=0
[  662.822828] usb 1-1.1: Setting usb interface 1:0 for EP 0x8
[  662.823054] usb 1-1.1: 1:1 Set sample rate 48000, clock 40
[  662.824597] usb 1-1.1: Setting params for data EP 0x8, pipe 0x40300
[  662.825831] usb 1-1.1: Set up 12 URBS, ret=0
[  662.825845] usb 1-1.1: Setting usb interface 1:1 for EP 0x8
[  662.826674] usb 1-1.1: Setting params for sync EP 0x84, pipe 0x20380
[  662.826803] usb 1-1.1: Set up 4 URBS, ret=0
[  662.839547] usb 1-1.1: Starting data EP 0x8 (running 0)
[  662.839827] usb 1-1.1: 12 URBs submitted for EP 0x8
[  662.839836] usb 1-1.1: Starting sync EP 0x84 (running 0)
[  662.839866] usb 1-1.1: 4 URBs submitted for EP 0x84
[  662.839873] usb 1-1.1: 1:1 Start Playback PCM

at playback stop (ctrl-c on speaker-test): 
[  726.783416] usb 1-1.1: Stopping sync EP 0x84 (running 1)
[  726.783447] usb 1-1.1: Stopping data EP 0x8 (running 1)
[  726.783485] usb 1-1.1: 1:1 Stop Playback PCM
[  726.808802] usb 1-1.1: Closing EP 0x8 (count 1)
[  726.808821] usb 1-1.1: EP 0x8 closed
[  726.808832] usb 1-1.1: Closing EP 0x84 (count 1)
[  726.808843] usb 1-1.1: Setting usb interface 1:0 for EP 0x84
[  726.809686] usb 1-1.1: EP 0x84 closed
Comment 32 Takashi Iwai 2022-05-16 11:34:02 UTC
OK, thanks.  The logs look good through a quick glance.

Does the stuttering happen no matter which sample rate and/or period size is used?  And it has nothing to do with the full duplex operation, right? (i.e. running a capture stream in parallel)
Comment 33 Luca Russel 2022-05-16 11:38:48 UTC
(In reply to Takashi Iwai from comment #32)
> OK, thanks.  The logs look good through a quick glance.
> 
> Does the stuttering happen no matter which sample rate and/or period size is
> used?  And it has nothing to do with the full duplex operation, right? (i.e.
> running a capture stream in parallel)


Yes it always happens, but it is influenced by rate: higher is the rate, more frequent is the stuttering.

Capture does not seems to influence it.
Comment 34 Takashi Iwai 2022-05-16 13:55:50 UTC
Hm, then it might be related with the packet size calculation.
Can you try the following hack?

--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -225,7 +225,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
 		return packet;
 	}
 
-	if (ep->sync_source)
+	if (0 && ep->sync_source)
 		return slave_next_packet_size(ep, avail);
 	else
 		return next_packet_size(ep, avail);
Comment 35 Takashi Iwai 2022-05-16 13:56:26 UTC
BTW, the patch for refcounting the clock source management was already submitted to the upstream, will be included in 5.19-rc1.
Comment 36 Luca Russel 2022-05-16 17:09:59 UTC
(In reply to Takashi Iwai from comment #35)
> BTW, the patch for refcounting the clock source management was already
> submitted to the upstream, will be included in 5.19-rc1.

Tried, stuttering is still there. 

For what it's worth, I noticed that on i7 machine, the stuttering, at 48khz, happens with a lower frequency (each 8/9 seconds) then on raspberry pi 4 (almost every second).
Comment 37 Ron L 2022-05-16 20:21:46 UTC
I'm going to ask something that might seem pretty stupid so bear with me.  Are you only experiencing this with speaker-test? It cuts out every time it does a loop. The lower the rate the longer the loop.  Playing it here on my laptop at 48000  it cuts out every 10.95 secs. At 96000 every 5.49 secs.  That is just how speaker-test runs from what I can tell.  Audio works perfectly on this laptop.  Anyway, point is I don't know how one would be able to tell the difference between an audio glitch caused by a driver issue or  the audio glitches made by speaker-test itself.
Comment 38 Luca Russel 2022-05-16 21:51:21 UTC
(In reply to Ron L from comment #37)
> [...] I don't know how one would be
> able to tell the difference between an audio glitch caused by a driver issue
> or  the audio glitches made by speaker-test itself.

Actually when I test I always use both speaker-test and YouTube playback from Firefox, and in both case I have the same stuttering on UMC 404 HD. 

Having said that, with pink noise speaker-test continuously loop over with no glitches of any kind on the main interface. The stuttering is audible only with UMC 404 HD.

Moreover, in that case, it should not be influenced by sample rate as it is.

> "The lower the rate the longer the loop." 
I would say, the lower the sample rate, the shorter is the period/buffer (max) size, not the time per period or the loop time length.
Comment 39 Takashi Iwai 2022-05-17 10:18:24 UTC
And does the bug appear when you use smaller buffer sizes, e.g.
  speaker-test -Dhw:xx -b 100 -P 4 -c 10
??
Comment 40 Luca Russel 2022-05-17 17:27:19 UTC
(In reply to Takashi Iwai from comment #39)
> And does the bug appear when you use smaller buffer sizes, e.g.
>   speaker-test -Dhw:xx -b 100 -P 4 -c 10
> ??

I tried the above command, on both main audio interface (intel) and UMC 404 HD.
On both I got a "Write Error 32; Broken Pipe". 

I repeated the command increasing the buffer parameter until I got no error.
For buffer <=2500 I still get the error, above is fine. 

On main interface the audio is strange, I distinguish some tones in the pink noise but there is no stuttering.

On the UMC 404 HD is the same situation but the stuttering is still there.

And the dependency on sample rate is still there.

Is there any other test or debug scenario I can produce to help understand ?
Comment 41 Luca Russel 2022-05-17 17:28:46 UTC
Ah sorry, I missed the minus, I mean: "Write Error -32; Broken Pipe".
Comment 42 Luca Russel 2022-05-17 17:29:13 UTC
Ah sorry, I missed the minus, I mean: "Write Error -32; Broken Pipe".
Comment 43 Takashi Iwai 2022-05-19 07:05:49 UTC
The EPIPE error means the buffer underrun, i.e. it couldn't process the data in time (usually a system latency problem).  But the stuttering problem seems irrelevant with the parameter.

Could you try the patch below?  It's a test fix for a bug that was reported for a TEAC device.
Comment 44 Takashi Iwai 2022-05-19 07:06:17 UTC
Created attachment 300992 [details]
Another test fix
Comment 45 Takashi Iwai 2022-05-19 09:02:08 UTC
Created attachment 300995 [details]
Another test fix (revised)
Comment 46 Luca Russel 2022-05-19 18:06:37 UTC
Just tried to apply the patch but it fails on hunk 4 at line 1382, this one:

@@ -1374,6 +1382,10 @@ static int init_sample_rate(struct snd_usb_audio *chip,
 
 	if (clock)
 		clock->rate = ep->cur_rate;
+
+	if (1 /*chip->quirk_flags & QUIRK_FLAG_SET_IFACE_AFTER_CLOCK*/)
+		endpoint_set_interface(chip, ep, true);
+
 	return 0;
 }


It seams that init_sample_rate(...) is not present in the endpoint.c file.
On kernels 5.15 and 5.18 it is in the file clock.c:
int snd_usb_init_sample_rate(struct snd_usb_audio *chip,
                             const struct audioformat *fmt, int rate)
{ ...

and for UAC 2 calls set_sample_rate_v2v3(chip, fmt, rate) in turn.
I could modify that function adding the above lines:
		endpoint_set_interface(chip, ep, true);

before the return line.
Comment 47 Luca Russel 2022-05-19 18:18:13 UTC
it fails since ep is not declared in the function.

Is there a way to get the endpoint?

--

  CC [M]  sound/usb/clock.o
sound/usb/clock.c: In function 'set_sample_rate_v2v3':
sound/usb/clock.c:580:9: error: implicit declaration of function 'endpoint_set_interface'; did you mean 'usb_set_interface'? [-Werror=implicit-function-declaration]
  580 |         endpoint_set_interface(chip, ep, true);
      |         ^~~~~~~~~~~~~~~~~~~~~~
      |         usb_set_interface
sound/usb/clock.c:580:38: error: 'ep' undeclared (first use in this function); did you mean 'up'?
  580 |         endpoint_set_interface(chip, ep, true);
Comment 48 Takashi Iwai 2022-05-20 11:55:11 UTC
The patch was on top of the latest sound git tree for-next branch.  But it turned out that this wasn't working properly for other devices, so scratch it.

The currently known workaround for a TEAC device is something like below.  It's interesting whether this has the effect on Behringer, too.
Comment 49 Takashi Iwai 2022-05-20 11:56:03 UTC
Created attachment 301007 [details]
A workaround patch for interface reset at clock change
Comment 50 Luca Russel 2022-05-20 17:04:05 UTC
Tested but no effect on stuttering (clock source 41 not valid message disappeared).

So it seems that the problem lies elsewhere.
Comment 51 Takashi Iwai 2022-05-22 10:24:35 UTC
So this doesn't look like an issue with the clock setup.

Just to be sure: does the playback stuttering appears also when you run arecord in the background?  e.g. start arecord at first, then start aplay (or speaker-test) with the sample sample rate and the period size.
Comment 52 Luca Russel 2022-05-22 10:30:08 UTC
Yes I confirm this, I tried this some days ago. Recording does not influence
stuttering.

I see in the kernel log the start of recording and following the start of 
playback and there is stuttering in the playback.

However I cannot say if stuttering happens also for the recorded data. 
If you think it is useful to know I will check this.
Comment 53 Takashi Iwai 2022-05-25 14:31:53 UTC
The recent fix patch for GoXLR might be relevant:
  https://bugzilla.kernel.org/show_bug.cgi?id=215079#c113

Could you give it a try with Behringer devices?
Comment 54 Ier 2022-05-27 06:36:04 UTC
(In reply to Takashi Iwai from comment #53)

Hello, I have a behringer UMC204HD with the same version bcdDevice=1.35 and with the exact same problem. I can help as often as I can however I don't have any prior experience patching or compiling kernels.

>The recent fix patch for GoXLR might be relevant:
>  https://bugzilla.kernel.org/show_bug.cgi?id=215079#c113
>
>Could you give it a try with Behringer devices?

I can help with that. Could you give me the exact directions?
Comment 55 Ier 2022-05-29 06:22:17 UTC
Update: I compiled and tested the kernel 5.18 with the GoXLR fix patch and the stuttering is still present.
Comment 56 Luca Russel 2022-05-30 07:28:07 UTC
(In reply to Takashi Iwai from comment #53)
> The recent fix patch for GoXLR might be relevant:
>   https://bugzilla.kernel.org/show_bug.cgi?id=215079#c113
> 
> Could you give it a try with Behringer devices?

Tested on 5.15 on Raspberry Pi 4 and on [5.13, 5.16, 5.18] on Intel i7 
and I also confirm that the stuttering is still there.
Comment 57 Luca Russel 2022-06-06 13:19:11 UTC
I managed to get in contact with Behringer folks but I got this reply:

---

Product:  Behringer UMC404HD 

Thank you for your patience whilst this matter is being looked into.
My colleague Nicolas is currently out of the office so I am following up on his behalf.
 
We have heard back from the Dev team who have notified us they are aware of the issue raised and are currently investigating this, however, at this moment in time cannot provide an ETA on when a fix will be released.
As also mentioned by my colleague Linux is, unfortunately, not a supported OS so we can only recommend in this instance to continue use with Windows or Mac OS.
 
At your service,
XXX

---


Sadly I think that a fix is not so close.
Comment 58 leo 2022-06-11 15:56:43 UTC
I also reached out to MusicTribe, owners of Behringer, and ended up with "I did some digging and they are just not supported at this time." I followed up asking if they're willing to provide any details on what the internal investigation revealed and haven't heard back yet.
Comment 59 nielszweistein 2022-06-14 06:22:15 UTC
hello, I have the new Behringer audio card UMC204HD.

BcdDevice= 1.35
dmesg -> clock source 41 not valid


When I add to /etc/modprobe.d   options snd_usb_audio implicit_fb=1

The card is working without stutering  only if i use Jack2 with Alsa Driver Backend
Comment 60 Luca Russel 2022-06-14 19:49:49 UTC
(In reply to nielszweistein from comment #59)
> hello, I have the new Behringer audio card UMC204HD.
> 
> BcdDevice= 1.35
> dmesg -> clock source 41 not valid
> 
> 
> When I add to /etc/modprobe.d   options snd_usb_audio implicit_fb=1
> 
> The card is working without stutering  only if i use Jack2 with Alsa Driver
> Backend


Yep this is consistent with other users experience: 
implicit_fb=1 is a workaround for UMC204HD but not for UMC404HD 

On UMC404HD , loading the module with implicit_fb=1 makes playback completely silent...
Comment 61 Takashi Iwai 2022-06-15 07:33:53 UTC
OK, could you guys check the behavior with the latest 5.19-rc2 or 5.18.x kernel?
We need to confirm that the already applied fix doesn't help alone.

And if it doesn't work, please check with quirk_flags=0x20010 option for snd-usb-audio driver.  (If you have multiple USB-audio devices, adjust the position for the option with a comma, e.g. for the second device, it'll be "quirk_flags=,0x20010")

The 0x20010 implies QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_GENERIC_IMPLICIT_FB
Comment 62 sergey 2022-06-15 09:07:13 UTC
Wow!

Takashi Iwai  thanks you!
it works!

 
Linux 5.18.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 09 Jun 2022 16:14:10 +0000 x86_64 GNU/Linux

> idVendor           0x1397 BEHRINGER International GmbH
> idProduct          0x0508
> bcdDevice            1.35
> iManufacturer           1 BEHRINGER
> iProduct                2 UMC204HD 192k

But "clock source 41 is not valid, cannot use" still present in dmesg messages.
Comment 63 sergey 2022-06-15 09:10:33 UTC
this is help:

>cat /etc/modprobe.d/snd_audio.conf
>options snd-usb-audio quirk_flags=0x20010
Comment 64 Takashi Iwai 2022-06-15 09:35:40 UTC
OK, good to hear.  Please let me know what you've tested.

FYI, "clock source 41 is not valid" looks like a generic problem on many devices, and it's more or less harmless; the validation for the very first clock setup fails by some reason, and after the retry, it starts working.
Comment 65 Takashi Iwai 2022-06-15 15:03:28 UTC
And below is a patch that is equivalent with quirk_flags=0x20010 option.
Comment 66 Takashi Iwai 2022-06-15 15:03:58 UTC
Created attachment 301180 [details]
Quirk table entries for Behringer devices
Comment 67 Luca Russel 2022-06-15 15:41:02 UTC
(In reply to Takashi Iwai from comment #66)
> Created attachment 301180 [details]
> Quirk table entries for Behringer devices

Hi Takashi, 

Thank you.

I will also test on both Rpi4 and Intel soon and report here.

On 5.15 and Rpi4 I tried those quirks (QUIRK_FLAG_PLAYBACK_FIRST and QUIRK_FLAG_GENERIC_IMPLICIT_FB) with no
success. Just to understand, it is changed something else in the last fix?
Comment 68 Takashi Iwai 2022-06-15 15:43:23 UTC
5.15 is way too old to debug, please test with the latest 5.18.x or 5.19-rc instead.
Comment 69 Luca Russel 2022-06-16 14:03:57 UTC
(In reply to Takashi Iwai from comment #68)
> 5.15 is way too old to debug, please test with the latest 5.18.x or 5.19-rc
> instead.

Yes, I was just asking why the same quirks did not work in 5.15.

In any case, I will absolutely test on the above ones.

Thank you!
Comment 70 Takashi Iwai 2022-06-17 05:41:45 UTC
(In reply to Luca Russel from comment #69)
> (In reply to Takashi Iwai from comment #68)
> > 5.15 is way too old to debug, please test with the latest 5.18.x or 5.19-rc
> > instead.
> 
> Yes, I was just asking why the same quirks did not work in 5.15.

Well, I'm not entirely sure whether the patch really works in all cases -- that's why we need more testing :)

One thing I can think of is, though, that you're testing with RPi.  It might be ARM has an issue with the memory coherency.  So better to test with x86 at first.
Comment 71 Luca Russel 2022-06-24 09:13:00 UTC
(In reply to Takashi Iwai from comment #70)
> (In reply to Luca Russel from comment #69)
> > (In reply to Takashi Iwai from comment #68)
> > > 5.15 is way too old to debug, please test with the latest 5.18.x or
> 5.19-rc
> > > instead.
> > 
> > Yes, I was just asking why the same quirks did not work in 5.15.
> 
> Well, I'm not entirely sure whether the patch really works in all cases --
> that's why we need more testing :)
> 
> One thing I can think of is, though, that you're testing with RPi.  It might
> be ARM has an issue with the memory coherency.  So better to test with x86
> at first.

Hi Takashi, 

I have tested on the following:

(1) x86_64 , 5.18.6 and 5.19-rc  without quirks
(2) Arm64 , 5.18.6 and 5.19-rc   without quirks
(3) x86_64 , 5.18.6 and 5.19-rc  with quirks
(4) Arm64 , 5.18.6 and 5.19-rc   with quirks

In (3) and (4) the card works without any stuttering. So far so good :)
In (1) and (2) stuttering is present like before.

I also want to report this strange behaviour, with both kernels, and in all cases (1-4): this time the stuttering appears on main audio interface but only when using plughw:PCH device while is perfect when using default:PCH. 
On the external interface (the behringer) it works like a charm when using quirks on all devices listed by aplay -L.
Comment 72 Takashi Iwai 2022-06-24 10:14:33 UTC
OK, now I submitted and merged the fix patch to sound git tree.
  https://lore.kernel.org/r/20220624101132.14528-1-tiwai@suse.de

Hopefully it'll be included in the upstream Linus tree soon.
(I'll be off in the next week, so the next PR will be after that week :)
Comment 73 Eva 2022-07-22 00:25:40 UTC
Same thing happens with UMC202HD interface, implicit_fb=1 option fixes it (bcdDevice is 1.00 though).
Hope the fix will be implemented for this model as well.
Comment 74 Takashi Iwai 2022-07-22 07:44:15 UTC
Please give alsa-info.sh output; run with --no-upload option and attach to Bugzilla.
Comment 75 Eva 2022-07-22 13:55:32 UTC
Created attachment 301474 [details]
Output of alsa-info --no-upload for UMC202HD
Comment 76 Takashi Iwai 2022-07-22 14:00:36 UTC
OK, below is the fix for UMC202HD.
Comment 77 Takashi Iwai 2022-07-22 14:01:34 UTC
Created attachment 301475 [details]
Fix patch for UMC202HD
Comment 78 Eva 2022-07-22 14:09:00 UTC
Thanks, hope it hits mainline soon.
Best regards
Comment 79 Nandakumar Edamana 2023-01-16 03:50:23 UTC
Really thankful that support for UMC devices are taken seriously. I have been
using `modprobe snd_usb_audio implicit_fb=1` to make UMC202HD playback work with
Linux 5.15.13. Recently I noticed that it wasn't working any more, and this
thread helped me in the sense that it made me upgrade the kernel to 5.19.0 and
UMC202HD is working fine either with `modprobe snd_usb_audio implicit_fb=1` or
with the permanent addition of the flags to modprobe.d configuration file. But
there are two things that puzzle me.

One, which is very important, is that the flags are not applied automatically
despite 5.19 having the quirks baked in
(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/usb/quirks.c?h=linux-5.19.y#n1804).

This is what `dmesg` with `modprobe snd_usb_audio dyndbg==p` says:

[65105.580355] usb 3-4: Open EP 0x8, iface=1:1, idx=0
[65105.580368] usb 3-4:   channels=2, rate=48000, format=S32_LE, period_bytes=4096, periods=64, implicit_fb=0
[65105.580377] usb 3-4: Open EP 0x84, iface=1:1, idx=1
[65105.580383] usb 3-4:   channels=2, rate=48000, format=S32_LE, period_bytes=4096, periods=64, implicit_fb=0

With `modprobe snd_usb_audio dyndbg==p implicit_fb=1`, it reports `implicit_fb=1` after `Open EP 0x8`.

In case you are wondering, yes, I've made sure the USB ids in the code and `lsusb` do match.

Second, I notice that multiple comments here mention the playback becoming
silent with `implicit_fb=1`. I had faced this too, and switching the
devices/profiles back and forth in pavucontrol would solve it in 5.15.13
(haven't had to do that yet in 5.19.0). Maybe that works for others too,
especially Luca Russel who mentioned that "implicit_fb=1 is a workaround for
UMC204HD but not for UMC404HD. On UMC404HD , loading the module with
implicit_fb=1 makes playback completely silent...".

But why was it silent in the first place and why would meddling with pavucontrol
profiles solve it?

And finally, could anybody please point me to any resource where I can
understand what implicit_fb is, what 'EP' is in 'Open EP 0x8', etc.?

Thank you.
Comment 80 D Penner 2023-03-03 00:22:35 UTC
Is it possible for the Linux kernel to support bcdDevice=1.35 and bcdDevice=1.12 simultaneously? I suspect that the changes to fix this bug for bcdDevice=1.35 may have caused some issues with the older bcdDevice=1.12. (I use an older Behringer UMC404HD with bcdDevice=1.12)

I ran into audio glitching issues, and it took me a while to try to isolate a root cause, until I was pointed to this thread from: https://forums.linuxmint.com/viewtopic.php?f=48&t=389635

While I don't really understand the technical details of the Linux Kernel, per help given to me in the above thread, I was able to determine that I run into my issues *only* on versions of the Ubuntu/Mint kernel where this change has been merged.

Thanks.
Comment 81 Nandakumar Edamana 2023-03-03 04:58:32 UTC
Follow-up to my last comment:

UMC202HD (1397:0507) playback works fine on Linux 6.2.1 without any manual intervention. Still no idea why it didn't work on 5.19.0.
Comment 82 Ron L 2023-03-03 17:37:58 UTC
I read through the topic on linuxmint forum and I can replicate the bug exactly with the current default Mint 21/Ubuntu 22.04 kernel with my original version 404HD.  It sounds like when the sound settings app is closed the device is re-initialized and playback starts again. I have not had time to test with a 6 version kernel or do any further debugging.  When audio is playing it seems fine. No glitches.

I'm not sure if this patch is what needs to be fixed.  It may have just triggered another bug in either the Sound Settings app or Pulseaudio and that maybe where the fix might be needed. Pulse is being replaced by Pipewire so might not even be an issue upstream.