Bug 215934

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).

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.

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.

I can also confirm that the bcdDevice= 1.12 revision works without flaws.

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

(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.

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.

Created attachment 300925 [details]
Alsa info from older model that is working without issue.

Created attachment 300926 [details]
alsa-info output

alsa-info.sh output form my config :
EMU 1820m sound card
NVIDIA HDMI
Behringer UMC 404 HD

@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.

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.

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?

Output of 'lsusb' for a Behringer 404 with bcdDevice= 1.12:

Bus 001 Device 006: ID 1397:0509 BEHRINGER International GmbH

Created attachment 300933 [details]
Bheringer UMC 404 HD bcdDevice=1.35 - LSUSB verbose - confirmed audio stuttering

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.

Created attachment 300935 [details]
output of 'lsusb -v'

Attached is the output of 'lsusb -v'. :)

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.

Created attachment 300937 [details]
lsusb -v for 1.12 device

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?

Created attachment 300938 [details]
Test fix for clock refecounting

(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?

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.

Created attachment 300942 [details]
Test fix for clock refecounting (v2)

(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.

I revised the patch again, now v3.

Created attachment 300944 [details]
Test fix for clock refecounting (v3)

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 ?

(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?

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?

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.

(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

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)

(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.

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);

BTW, the patch for refcounting the clock source management was already submitted to the upstream, will be included in 5.19-rc1.

(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).

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.

(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.

And does the bug appear when you use smaller buffer sizes, e.g.
  speaker-test -Dhw:xx -b 100 -P 4 -c 10
??

(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 ?

Ah sorry, I missed the minus, I mean: "Write Error -32; Broken Pipe".

Ah sorry, I missed the minus, I mean: "Write Error -32; Broken Pipe".

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.

Created attachment 300992 [details]
Another test fix

Created attachment 300995 [details]
Another test fix (revised)

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.

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);

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.

Created attachment 301007 [details]
A workaround patch for interface reset at clock change

Tested but no effect on stuttering (clock source 41 not valid message disappeared).

So it seems that the problem lies elsewhere.

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.

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.

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?

(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?

Update: I compiled and tested the kernel 5.18 with the GoXLR fix patch and the stuttering is still present.

(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.

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.

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.

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

(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...

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

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.

this is help:

>cat /etc/modprobe.d/snd_audio.conf
>options snd-usb-audio quirk_flags=0x20010

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.

And below is a patch that is equivalent with quirk_flags=0x20010 option.

Created attachment 301180 [details]
Quirk table entries for Behringer devices

(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?

5.15 is way too old to debug, please test with the latest 5.18.x or 5.19-rc instead.

(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!

(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.

(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.

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 :)

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.

Please give alsa-info.sh output; run with --no-upload option and attach to Bugzilla.

Created attachment 301474 [details]
Output of alsa-info --no-upload for UMC202HD

OK, below is the fix for UMC202HD.

Created attachment 301475 [details]
Fix patch for UMC202HD

Thanks, hope it hits mainline soon.
Best regards

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.

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.

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.

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.