Since upgrading to 5.19.9 my Steinberg UR22C audio interface only shows input or output audio profiles and setting it to "Pro Audio" results in this error message with pipewire and only output works: ``` Sep 17 21:00:26 tynan pipewire[21886]: spa.alsa: set_hw_params: Device or resource busy Sep 17 21:00:26 tynan pipewire[21886]: pw.node: (alsa_input.usb-Yamaha_Corporation_Steinberg_UR22C-00.pro-input-0-95) suspended -> error (Start error: Device or resource busy) ``` With 5.19.9 only audio output profile or audio input profiles work as the combined ones are missing completely. Downgrading to 5.19.8 results in the interface showing all the profiles again and it works like before. I also tried 6.0rc5 which exhibits the same regression. Downgrading any pipewire components also didn't help and only the kernel version made a difference.
I can confirm the same issue and behavior is present on the Behringer UMC404HD and Focusrite Scarlett 2i2 usb audio interfaces. Downgrading to 5.19.8 also restored normal functionality for me on both devices
There are a few different fixes between those two versions about USB-audio (sound/usb/audio/*). Could you bisect which one broke?
(In reply to Takashi Iwai from comment #2) > There are a few different fixes between those two versions about USB-audio > (sound/usb/audio/*). Could you bisect which one broke? yes, currently trying that. will update if/when i find the offending one.
Looking through the commit log i suspected that most likely https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.19.y&id=271f862ebc60b3a7ff1563654eb33cd4571c66aa is the culprit and reverting this single commit worked. also pretty sure that https://bugzilla.kernel.org/show_bug.cgi?id=216499 is the exact same issue.
I can confirm reverting that commit also fixes https://bugzilla.kernel.org/show_bug.cgi?id=216499 .
Thanks. Could you try the patch below? If that doesn't work, I'll revert the commit instead.
Created attachment 301829 [details] Test fix patch
*** Bug 216499 has been marked as a duplicate of this bug. ***
Created attachment 301830 [details] Test fix patch (corrected)
That seems to have worked, just trying a clean build with the patch too, just in case.
Great, thanks for quick testing!
Created attachment 301832 [details] The fix patch to be submitted
I just tried it with a clean build, and either something went wrong with applying the patch or it's still not working. I'll try one more time with the non-distribution tree (i had dirty mainline first, then clean arch latest which failed).
Tried a clean 5.19.9 with only this patch applied and unfortunately it's still broken.
Same, unfortunately applying attachment 301832 [details] on top of 5.19.9 doesn't fix the issue for me.
Just to be sure, check with the patch in comment 9?
(In reply to Takashi Iwai from comment #16) > Just to be sure, check with the patch in comment 9? Yes, it was.
Hrm, so both the patches in comment 9 and comment 12 didn't work on top of 6.0-rc[56]? Could you try to load snd-usb-audio module with dyndbg=+p option, and attach the dmesg output? It should show the debug print "Mismatched sample rate X vs Y...", if I understand correctly.
I have which appears to be the same issue with a MOTU M2 and kernel 5.15.68 Did this bug make it to the 5.15 branch? ``` sep 20 11:05:49 yoda pipewire[1026110]: spa.alsa: set_hw_params: Device or resource busy sep 20 11:05:49 yoda pipewire[1026110]: pw.node: (alsa_input.usb-MOTU_M2_M2MT08FB8F-00.pro-input-0-96) suspended -> error (Start error: Device or resource bus> sep 20 11:05:49 yoda pipewire[1026110]: spa.alsa: set_hw_params: Device or resource b ```
(In reply to Takashi Iwai from comment #18) > Hrm, so both the patches in comment 9 and comment 12 didn't work on top of > 6.0-rc[56]? > > Could you try to load snd-usb-audio module with dyndbg=+p option, and attach > the dmesg output? It should show the debug print "Mismatched sample rate X > vs Y...", if I understand correctly. Did something substantial change between patches in comment 9 and 12? I only tried the one in 9 with both 5.19.9 and 6.0rc5 where it didn't work for either kernel.
(In reply to Zoé B from comment #20) > (In reply to Takashi Iwai from comment #18) > > Hrm, so both the patches in comment 9 and comment 12 didn't work on top of > > 6.0-rc[56]? > > > > Could you try to load snd-usb-audio module with dyndbg=+p option, and > attach > > the dmesg output? It should show the debug print "Mismatched sample rate X > > vs Y...", if I understand correctly. > > Did something substantial change between patches in comment 9 and 12? I only > tried the one in 9 with both 5.19.9 and 6.0rc5 where it didn't work for > either kernel. No substantial, but only small difference. I asked it just to be sure whether there was any thinko at refactoring. In anyway, below is another pitch. Hopefully this works better... If it still doesn't work, I'm going to simply revert the commit mentioned in comment 4.
Created attachment 301833 [details] v2 fix patch Should be applicable to 5.19.y and 6.0-rc
(In reply to Nicolas Goy from comment #19) > I have which appears to be the same issue with a MOTU M2 and kernel 5.15.68 > > Did this bug make it to the 5.15 branch? Yes, likely. Try to revert the stable commit df5ec554e9e35110971381e7c658ef945ace9905 (upstream ff878b408a03bef5d610b7e2302702e16a53636e).
(In reply to Takashi Iwai from comment #22) > Created attachment 301833 [details] > v2 fix patch > > Should be applicable to 5.19.y and 6.0-rc Thank you! building with 6.0rc6 right now.
Still doesn't work with the patch from comment 22 on 6.0-rc6 unfortunately...
OK, then it's something different from what I was looking at. Could you give the kernel log taking after loading snd-usb-audio with dyndbg=+p option and reproducing the bug?
Meanwhile I submitted the revert now: https://lore.kernel.org/r/20220920113929.25162-1-tiwai@suse.de It'll be likely included in 6.0-rc7 and backported to 5.15 and 5.19 stable eventually later. But, let's keep debugging for a while with the buggy commit. I need to understand what went south, above all.
Created attachment 301834 [details] Debug log from snd-usb-audio
(In reply to Takashi Iwai from comment #26) > OK, then it's something different from what I was looking at. > > Could you give the kernel log taking after loading snd-usb-audio with > dyndbg=+p option and reproducing the bug? I attached the log output, it's a bit more than just the audio interface only because it's currently on a docking station. I can also do a attach with only the interface if necessary.
Thanks, that's fine, I can just grep "6-1.2.1" for the relevant messages. Interestingly there was no error there in the log, so from the driver POV, it worked as expected. Do I understand correctly that it's a broken state, right?
It's broken in the sense of that it doesn't enumerate all the possible configurations. It works only as output or input but not both at the same time. If I choose "Pro Audio" as the configuration it shows an input too, but that input then does not work at all. Before the commit that broke this, it showed configurations for Output + Input and the Pro Audio configuration also worked as Output + Input simultaneously.
Could you apply the debug patch below on the top and give the log again with dyndbg=+p?
Created attachment 301835 [details] debug patch
Created attachment 301836 [details] Debug log with additional debug patch Debug log of attaching the audio interface directly.
I guess the patch wasn't applied or installed? The patched kernel should show debug messages with "XXX ..."
(In reply to Takashi Iwai from comment #35) > I guess the patch wasn't applied or installed? The patched kernel should > show debug messages with "XXX ..." right, i named it wrong so it didn't get applied in the build, trying again.
Created attachment 301837 [details] Debug log with additional debug patch, v2
Thanks! Could you try the fix patch below? (You can scratch the previous debug patch.)
Created attachment 301838 [details] Another fix patch
The combination of patches worked now, thanks a lot!
Thanks, finally nailed down. So I scratched on another (potential) bug of the patch at first, then hit the right one now. Below is the v2 patch for the buggy commit. It'd be helpful if you can try this once after reverting the commit ff878b408a03 on top of the clean latest Linus tree (or 6.0-rc[56]) (i.e. without previous fix patches).
Created attachment 301839 [details] v2 patch for endpoint setup split
(In reply to Takashi Iwai from comment #41) > Thanks, finally nailed down. So I scratched on another (potential) bug of > the patch at first, then hit the right one now. > > Below is the v2 patch for the buggy commit. It'd be helpful if you can try > this once after reverting the commit ff878b408a03 on top of the clean latest > Linus tree (or 6.0-rc[56]) (i.e. without previous fix patches). This works with 6.0-rc6, ff878b408a03 reverted and only the patch in comment 42.
And I can confirm 6.0-rc6 with ff878b408a03 reverted and the patch in attachment 301839 [details] works for MOTU M2 as well.
*** Bug 216508 has been marked as a duplicate of this bug. ***
Thanks for confirmation. I'll submit the revised patch (but destined for 6.1). 6.0 and stable will receive the revert in a couple of days.
For reference, I confirm that the bug made it to the 5.15 branch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/sound/usb/endpoint.c?id=v5.15.68&id2=v5.15.67
Just want to add another report. After upgrading to kernel 5.19.10 today (was previously on 5.19.8) my soundcard isn't detected by the kernel. Or rather it errors with: [ 939.487513] usb 1-2: USB disconnect, device number 3 [ 942.497809] usb 1-2: new high-speed USB device number 4 using xhci_hcd [ 942.640650] usb 1-2: New USB device found, idVendor=2708, idProduct=0009, bcdDevice= 1.07 [ 942.640656] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 942.640658] usb 1-2: Product: Audient iD4 [ 942.640660] usb 1-2: Manufacturer: Audient [ 943.691605] usb 1-2: 60:0: cannot get min/max values for control 1 (id 60) [ 943.695600] usb 1-2: 60:0: cannot get min/max values for control 3 (id 60) [ 943.696225] usb 1-2: 60:0: cannot get min/max values for control 4 (id 60) [ 943.697225] usb 1-2: 11:0: cannot get min/max values for control 11 (id 11) [ 943.699983] input: Audient Audient iD4 as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.1/usb1/1-2/1-2:1.3/0003:2708:0009.0008/input/input28 [ 943.700067] hid-generic 0003:2708:0009.0008: input,hidraw1: USB HID v1.10 Mouse [Audient Audient iD4] on usb-0000:06:00.1-2/input3 [ 943.737731] usb 1-2: 60:0: cannot get min/max values for control 1 (id 60) [ 943.737979] usb 1-2: 60:0: cannot get min/max values for control 3 (id 60) [ 943.738219] usb 1-2: 60:0: cannot get min/max values for control 4 (id 60) [ 943.738465] usb 1-2: 11:0: cannot get min/max values for control 11 (id 11) [ 943.738716] usb 1-2: 60:0: cannot get min/max values for control 1 (id 60) [ 943.738965] usb 1-2: 60:0: cannot get min/max values for control 3 (id 60) [ 943.739216] usb 1-2: 60:0: cannot get min/max values for control 4 (id 60) [ 943.739464] usb 1-2: 11:0: cannot get min/max values for control 11 (id 11) [ 943.739715] usb 1-2: 60:0: cannot get min/max values for control 1 (id 60) [ 943.742217] usb 1-2: 60:0: cannot get min/max values for control 3 (id 60) [ 943.743965] usb 1-2: 60:0: cannot get min/max values for control 4 (id 60) [ 943.744966] usb 1-2: 11:0: cannot get min/max values for control 11 (id 11) My soundcard is: Bus 001 Device 003: ID 2708:0009 Audient Audient iD4
(In reply to skogsmaskin from comment #48) > Just want to add another report. > > After upgrading to kernel 5.19.10 today (was previously on 5.19.8) my > soundcard isn't detected by the kernel. Or rather it errors with: Looks like a different issue. Please don't mix up, but open another report. At best, try git bisection to hunt the regression cause.
I can confirm the same issue and behavior is present on the Behringer UMC404HD usb audio interface. Downgrading to 5.19.8 also restored normal functionality for me. I'v also tried with negative results: linux 5.19.10.artix1-1 linux-lts 5.15.70-1 linux-zen 5.19.10.zen1-1
same as angelettif@gmail.com, but i have a behringer umc202hd.
Mismo problema endeavouros kernel 5.19.9/10-11 Interface: audient id4
The issue still exists. Card: Audient iD4 (2708:0009) Kernel: 5.19.11-zen1-1-zen
I've run into this issue on my Edirol UA-25 interface and kernel 5.19.11-200.fc36.x86_64. See: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2732
FIXED! Working perfect with the new kernel 5.19.12 Thank you very much!
Works for the Audient id4 again now also with v5.19.12. Great!
Works for Behringer UMC404HD agin with 5.19.12-zen1-1-zen