I'm currently experiencing a regression with the audio on my Behringer U-Phoria UMC404HD.
Alsa info is at: http://alsa-project.org/db/?f=f453b8cd0248fb5fdfa38e1b770e774102f66135
I get no audio in or out for this device with kernel versions 6.1.1 and 6.1.2.
The versions I have tried that work correctly include 5.15.86 LTS, 5.19.12, and 6.0.13–16.
When I run this on 6.1.1, it will just hang until I ctrl+c: aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Center.wav
I've run strace on that command, and its output is at: https://pastebin.com/WaxJpTMe
Nothing out of the ordinary occurs when aplay is run, according to the kernel logs.
Please let me know how I can provide additional debugging information if necessary.
Thanks Michael
For comparison, on a working kernel version, my audio devices are listed in a different order: http://alsa-project.org/db/?f=eff15e3b674b313f12121c95d4cf330f9d48897c
-- Michael
On Tue, 3 Jan 2023 at 04:29, Michael Ralston michael@ralston.id.au wrote:
I'm currently experiencing a regression with the audio on my Behringer U-Phoria UMC404HD.
Alsa info is at: http://alsa-project.org/db/?f=f453b8cd0248fb5fdfa38e1b770e774102f66135
I get no audio in or out for this device with kernel versions 6.1.1 and 6.1.2.
The versions I have tried that work correctly include 5.15.86 LTS, 5.19.12, and 6.0.13–16.
When I run this on 6.1.1, it will just hang until I ctrl+c: aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Center.wav
I've run strace on that command, and its output is at: https://pastebin.com/WaxJpTMe
Nothing out of the ordinary occurs when aplay is run, according to the kernel logs.
Please let me know how I can provide additional debugging information if necessary.
Thanks Michael
[TLDR: I'm adding this report to the list of tracked Linux kernel regressions; all text you find below is based on a few templates paragraphs you might have encountered already already in similar form. See link in footer if these mails annoy you.]
[CCing alsa maintainers]
On 02.01.23 18:29, Michael Ralston wrote:
I'm currently experiencing a regression with the audio on my Behringer U-Phoria UMC404HD.
Alsa info is at: http://alsa-project.org/db/?f=f453b8cd0248fb5fdfa38e1b770e774102f66135
I get no audio in or out for this device with kernel versions 6.1.1 and 6.1.2.
The versions I have tried that work correctly include 5.15.86 LTS, 5.19.12, and 6.0.13–16.
When I run this on 6.1.1, it will just hang until I ctrl+c: aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Center.wav
I've run strace on that command, and its output is at: https://pastebin.com/WaxJpTMe
Nothing out of the ordinary occurs when aplay is run, according to the kernel logs.
Please let me know how I can provide additional debugging information if necessary.
Thanks for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot:
#regzbot ^introduced v6.0..v6.1 #regzbot title alsa: usb: audio stopped working #regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail.
Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (see page linked in footer for details).
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
On Tue, 03 Jan 2023 10:07:42 +0100, Thorsten Leemhuis wrote:
[TLDR: I'm adding this report to the list of tracked Linux kernel regressions; all text you find below is based on a few templates paragraphs you might have encountered already already in similar form. See link in footer if these mails annoy you.]
[CCing alsa maintainers]
On 02.01.23 18:29, Michael Ralston wrote:
I'm currently experiencing a regression with the audio on my Behringer U-Phoria UMC404HD.
Alsa info is at: http://alsa-project.org/db/?f=f453b8cd0248fb5fdfa38e1b770e774102f66135
I get no audio in or out for this device with kernel versions 6.1.1 and 6.1.2.
The versions I have tried that work correctly include 5.15.86 LTS, 5.19.12, and 6.0.13–16.
When I run this on 6.1.1, it will just hang until I ctrl+c: aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Center.wav
I've run strace on that command, and its output is at: https://pastebin.com/WaxJpTMe
Nothing out of the ordinary occurs when aplay is run, according to the kernel logs.
Please let me know how I can provide additional debugging information if necessary.
Please boot with snd_usb_audio.dyndbg=+p option, and get the kernel logs in both working and non-working cases.
I guess it's a regression due to the hw_params/prepare split, but need to check more details.
thanks,
Takashi
Working, 6.0.16-lqx1 https://hastebin.com/omoqasiqek.apache
Not working, 6.1.1-arch1-1.1 https://hastebin.com/itasefinaz.apache
I built the working kernel myself with patched sources. Let me know if you'd like me to run a test with any particular kernel build or version.
-- Michael
On Tue, 3 Jan 2023 at 20:33, Takashi Iwai tiwai@suse.de wrote:
On Tue, 03 Jan 2023 10:07:42 +0100, Thorsten Leemhuis wrote:
[TLDR: I'm adding this report to the list of tracked Linux kernel regressions; all text you find below is based on a few templates paragraphs you might have encountered already already in similar form. See link in footer if these mails annoy you.]
[CCing alsa maintainers]
On 02.01.23 18:29, Michael Ralston wrote:
I'm currently experiencing a regression with the audio on my Behringer U-Phoria UMC404HD.
Alsa info is at: http://alsa-project.org/db/?f=f453b8cd0248fb5fdfa38e1b770e774102f66135
I get no audio in or out for this device with kernel versions 6.1.1 and 6.1.2.
The versions I have tried that work correctly include 5.15.86 LTS, 5.19.12, and 6.0.13–16.
When I run this on 6.1.1, it will just hang until I ctrl+c: aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Center.wav
I've run strace on that command, and its output is at: https://pastebin.com/WaxJpTMe
Nothing out of the ordinary occurs when aplay is run, according to the kernel logs.
Please let me know how I can provide additional debugging information if necessary.
Please boot with snd_usb_audio.dyndbg=+p option, and get the kernel logs in both working and non-working cases.
I guess it's a regression due to the hw_params/prepare split, but need to check more details.
thanks,
Takashi
On Tue, 03 Jan 2023 14:10:46 +0100, Michael Ralston wrote:
Working, 6.0.16-lqx1 https://hastebin.com/omoqasiqek.apache
Not working, 6.1.1-arch1-1.1 https://hastebin.com/itasefinaz.apache
I built the working kernel myself with patched sources. Let me know if you'd like me to run a test with any particular kernel build or version.
Thanks, that's helpful.
Could you try to revert the commit 9902b303b5ade208b58f0dd38a09831813582211 ALSA: usb-audio: Avoid unnecessary interface change at EP close as a blind shot?
Also, there has been a series of fixes for other issues, and it might be worth to try as well: https://lore.kernel.org/r/20230102170759.29610-1-tiwai@suse.de
Takashi
On Wed, 4 Jan 2023 at 00:38, Takashi Iwai tiwai@suse.de wrote:
Thanks; that's helpful.
Could you try to revert the commit 9902b303b5ade208b58f0dd38a09831813582211 ALSA: usb-audio: Avoid unnecessary interface change at EP close
as a blind shot?
Also, there has been a series of fixes for other issues, and it might be worth to try as well: https://lore.kernel.org/r/20230102170759.29610-1-tiwai@suse.de
I built 3 kernels: one with the reverted commit, one with the patches you linked, and one with both. These builds were based on 6.1.2.
None of them worked. Also, even though I continued to boot with snd_usb_audio.dyndbg=+p, none of the kernel logs showed the debug messages that the other versions did. I'm baffled why this is.
I did notice that the order that the detected sound devices appeared in alsa was varying. That's probably not relevant though.
Links to logs:
Revert only https://hastebin.com/avinasiruj.apache
New patches only https://hastebin.com/aqepesokam.apache
Both https://hastebin.com/igilaqujus.apache
-- Michael
On Tue, 03 Jan 2023 16:05:18 +0100, Michael Ralston wrote:
On Wed, 4 Jan 2023 at 00:38, Takashi Iwai tiwai@suse.de wrote:
Thanks; that's helpful.
Could you try to revert the commit 9902b303b5ade208b58f0dd38a09831813582211 ALSA: usb-audio: Avoid unnecessary interface change at EP close
as a blind shot?
Also, there has been a series of fixes for other issues, and it might be worth to try as well: https://lore.kernel.org/r/20230102170759.29610-1-tiwai@suse.de
I built 3 kernels: one with the reverted commit, one with the patches you linked, and one with both. These builds were based on 6.1.2.
None of them worked. Also, even though I continued to boot with snd_usb_audio.dyndbg=+p, none of the kernel logs showed the debug messages that the other versions did. I'm baffled why this is.
That's weird. Is snd_usb_audio driver bound with the device at all? That is, does it appear in /proc/asound/cards?
Takashi
On Wed, 4 Jan 2023 at 02:13, Takashi Iwai tiwai@suse.de wrote:
That's weird. Is snd_usb_audio driver bound with the device at all? That is, does it appear in /proc/asound/cards?
Yes, it's there.
0 [V49 ]: USB-Audio - V49 Alesis V49 at usb-0000:08:00.1-3, full speed 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfc080000 irq 154 2 [U192k ]: USB-Audio - UMC404HD 192k BEHRINGER UMC404HD 192k at usb-0000:08:00.1-4, high speed 3 [Generic ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xfca00000 irq 156
-- Michael
On Wed, 4 Jan 2023 at 02:14, Michael Ralston michael@ralston.id.au wrote:
On Wed, 4 Jan 2023 at 02:13, Takashi Iwai tiwai@suse.de wrote:
That's weird. Is snd_usb_audio driver bound with the device at all? That is, does it appear in /proc/asound/cards?
Yes, it's there.
0 [V49 ]: USB-Audio - V49 Alesis V49 at usb-0000:08:00.1-3, full speed 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfc080000 irq 154 2 [U192k ]: USB-Audio - UMC404HD 192k BEHRINGER UMC404HD 192k at usb-0000:08:00.1-4, high speed 3 [Generic ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xfca00000 irq 156
Also lsusb shows this...
|__ Port 4: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 480M ID 1397:0509 BEHRINGER International GmbH /sys/bus/usb/devices/1-4 /dev/bus/usb/001/005 |__ Port 4: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 480M ID 1397:0509 BEHRINGER International GmbH /sys/bus/usb/devices/1-4 /dev/bus/usb/001/005 |__ Port 4: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 480M ID 1397:0509 BEHRINGER International GmbH /sys/bus/usb/devices/1-4 /dev/bus/usb/001/005 |__ Port 4: Dev 5, If 3, Class=Audio, Driver=snd-usb-audio, 480M ID 1397:0509 BEHRINGER International GmbH /sys/bus/usb/devices/1-4 /dev/bus/usb/001/005 |__ Port 4: Dev 5, If 4, Class=Audio, Driver=snd-usb-audio, 480M ID 1397:0509 BEHRINGER International GmbH /sys/bus/usb/devices/1-4 /dev/bus/usb/001/005 |__ Port 4: Dev 5, If 5, Class=Vendor Specific Class, Driver=, 480M ID 1397:0509 BEHRINGER International GmbH /sys/bus/usb/devices/1-4 /dev/bus/usb/001/005
-- Michael
On Tue, 03 Jan 2023 16:14:57 +0100, Michael Ralston wrote:
On Wed, 4 Jan 2023 at 02:13, Takashi Iwai tiwai@suse.de wrote:
That's weird. Is snd_usb_audio driver bound with the device at all? That is, does it appear in /proc/asound/cards?
Yes, it's there.
0 [V49 ]: USB-Audio - V49 Alesis V49 at usb-0000:08:00.1-3, full speed 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfc080000 irq 154 2 [U192k ]: USB-Audio - UMC404HD 192k BEHRINGER UMC404HD 192k at usb-0000:08:00.1-4, high speed 3 [Generic ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xfca00000 irq 156
Hrm... Try to reload snd_usb_audio module with the dyndbg=+p option, e.g.
# modprobe -r snd-usb-audio # modprobe snd_usb_audio dyndbg=+p
Or you can try to put your own debug printk(); we need to make sure whether it's really the right code you're testing at first.
Takashi
On Wed, 4 Jan 2023 at 02:21, Takashi Iwai tiwai@suse.de wrote:
Hrm... Try to reload snd_usb_audio module with the dyndbg=+p option, e.g.
# modprobe -r snd-usb-audio # modprobe snd_usb_audio dyndbg=+p
Or you can try to put your own debug printk(); we need to make sure whether it's really the right code you're testing at first.
Ok, it looks like it was ignoring the kernel command line for some reason. modprobing it with the option brought up debug messages again.
I'm still running kernel 6.1.2 vanilla with the revert and the patches.
aplay hung again when I ran it, the kernel was stuck on: Jan 04 02:25:59 leatherback kernel: usb 1-4: 1:1 Start Playback PCM
and didn't output another line until I ctrl+c aplay.
Jan 04 02:25:27 leatherback kernel: mc: Linux media interface: v0.10 Jan 04 02:25:27 leatherback kernel: usb 1-3: Found last interface = 1 Jan 04 02:25:27 leatherback kernel: usb 1-4: Set quirk_flags 0x20010 for device 1397:0509 Jan 04 02:25:27 leatherback kernel: usb 1-4: Found last interface = 4 Jan 04 02:25:27 leatherback kernel: usb 1-4: 1:1: added playback implicit_fb sync_ep 88, iface 2:1 Jan 04 02:25:27 leatherback kernel: usb 1-4: 1:1: add audio endpoint 0x8 Jan 04 02:25:27 leatherback kernel: usb 1-4: Creating new data endpoint #8 Jan 04 02:25:27 leatherback kernel: usb 1-4: Creating new data endpoint #88 Jan 04 02:25:27 leatherback kernel: usb 1-4: 2:1: add audio endpoint 0x88 Jan 04 02:25:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Switch] ch = 4, val = 0/1/1 Jan 04 02:25:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Switch] ch = 1, val = 0/1/1 Jan 04 02:25:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Volume] ch = 4, val = -32512/0/256 Jan 04 02:25:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Volume] ch = 1, val = -32512/0/256 Jan 04 02:25:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Switch] ch = 4, val = 0/1/1 Jan 04 02:25:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Switch] ch = 1, val = 0/1/1 Jan 04 02:25:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Volume] ch = 4, val = -32512/0/256 Jan 04 02:25:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Volume] ch = 1, val = -32512/0/256 Jan 04 02:25:27 leatherback kernel: usbcore: registered new interface driver snd-usb-audio Jan 04 02:25:59 leatherback kernel: usb 1-4: Open EP 0x8, iface=1:1, idx=0 Jan 04 02:25:59 leatherback kernel: usb 1-4: channels=4, rate=48000, format=S32_LE, period_bytes=96000, periods=4, implicit_fb=1 Jan 04 02:25:59 leatherback kernel: usb 1-4: Open EP 0x88, iface=2:1, idx=0 Jan 04 02:25:59 leatherback kernel: usb 1-4: channels=4, rate=48000, format=S32_LE, period_bytes=96000, periods=4, implicit_fb=0 Jan 04 02:25:59 leatherback kernel: usb 1-4: Setting params for data EP 0x88, pipe 0x40580 Jan 04 02:25:59 leatherback kernel: usb 1-4: Set up 12 URBS, ret=0 Jan 04 02:25:59 leatherback kernel: usb 1-4: Setting params for data EP 0x8, pipe 0x40500 Jan 04 02:25:59 leatherback kernel: usb 1-4: Set up 12 URBS, ret=0 Jan 04 02:25:59 leatherback kernel: usb 1-4: Setting usb interface 2:0 for EP 0x88 Jan 04 02:25:59 leatherback kernel: usb 1-4: 2:1 Set sample rate 48000, clock 40 Jan 04 02:25:59 leatherback kernel: usb 1-4: Setting usb interface 2:1 for EP 0x88 Jan 04 02:25:59 leatherback kernel: usb 1-4: Setting usb interface 1:0 for EP 0x8 Jan 04 02:25:59 leatherback kernel: usb 1-4: Setting usb interface 1:1 for EP 0x8 Jan 04 02:25:59 leatherback kernel: usb 1-4: Starting data EP 0x8 (running 0) Jan 04 02:25:59 leatherback kernel: usb 1-4: 12 URBs submitted for EP 0x8 Jan 04 02:25:59 leatherback kernel: usb 1-4: Starting data EP 0x88 (running 0) Jan 04 02:25:59 leatherback kernel: usb 1-4: 12 URBs submitted for EP 0x88 Jan 04 02:25:59 leatherback kernel: usb 1-4: 1:1 Start Playback PCM Jan 04 02:26:20 leatherback kernel: usb 1-4: Stopping data EP 0x88 (running 1) Jan 04 02:26:20 leatherback kernel: usb 1-4: Stopping data EP 0x8 (running 1) Jan 04 02:26:20 leatherback kernel: usb 1-4: 1:1 Stop Playback PCM Jan 04 02:26:20 leatherback kernel: usb 1-4: Closing EP 0x8 (count 1) Jan 04 02:26:20 leatherback kernel: usb 1-4: Setting usb interface 1:0 for EP 0x8 Jan 04 02:26:20 leatherback kernel: usb 1-4: EP 0x8 closed Jan 04 02:26:20 leatherback kernel: usb 1-4: Closing EP 0x88 (count 1) Jan 04 02:26:20 leatherback kernel: usb 1-4: Setting usb interface 2:0 for EP 0x88 Jan 04 02:26:20 leatherback kernel: usb 1-4: EP 0x88 closed
On Tue, 03 Jan 2023 16:31:13 +0100, Michael Ralston wrote:
On Wed, 4 Jan 2023 at 02:21, Takashi Iwai tiwai@suse.de wrote:
Hrm... Try to reload snd_usb_audio module with the dyndbg=+p option, e.g.
# modprobe -r snd-usb-audio # modprobe snd_usb_audio dyndbg=+p
Or you can try to put your own debug printk(); we need to make sure whether it's really the right code you're testing at first.
Ok, it looks like it was ignoring the kernel command line for some reason. modprobing it with the option brought up debug messages again.
I'm still running kernel 6.1.2 vanilla with the revert and the patches.
aplay hung again when I ran it, the kernel was stuck on: Jan 04 02:25:59 leatherback kernel: usb 1-4: 1:1 Start Playback PCM
and didn't output another line until I ctrl+c aplay.
OK, thanks. Then it's not about the USB interface reset. It must be subtle and nasty difference.
Could you apply the change below on the top? It essentially reverts the hw_params/prepare split again.
Takashi
-- 8< -- --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -564,6 +564,21 @@ static int snd_usb_hw_params(struct snd_pcm_substream *substream, }
ret = snd_usb_endpoint_set_params(chip, subs->data_endpoint); + if (ret < 0) + goto unlock; + + if (subs->sync_endpoint) { + ret = snd_usb_endpoint_prepare(chip, subs->sync_endpoint); + if (ret < 0) + goto unlock; + } + + ret = snd_usb_endpoint_prepare(chip, subs->data_endpoint); + if (ret < 0) + goto unlock; + else if (ret > 0) + snd_usb_set_format_quirk(subs, subs->cur_audiofmt); + ret = 0;
unlock: if (ret < 0)
On Wed, 4 Jan 2023 at 03:03, Takashi Iwai tiwai@suse.de wrote:
OK, thanks. Then it's not about the USB interface reset. It must be subtle and nasty difference.
Could you apply the change below on the top? It essentially reverts the hw_params/prepare split again.
Very sorry to say this still hasn't fixed the problem :(
Jan 04 06:05:12 leatherback kernel: mc: Linux media interface: v0.10 Jan 04 06:05:12 leatherback kernel: usb 1-3: Found last interface = 1 Jan 04 06:05:12 leatherback kernel: usb 1-4: Set quirk_flags 0x20010 for device 1397:0509 Jan 04 06:05:12 leatherback kernel: usb 1-4: Found last interface = 4 Jan 04 06:05:12 leatherback kernel: usb 1-4: 1:1: added playback implicit_fb sync_ep 88, iface 2:1 Jan 04 06:05:12 leatherback kernel: usb 1-4: 1:1: add audio endpoint 0x8 Jan 04 06:05:12 leatherback kernel: usb 1-4: Creating new data endpoint #8 Jan 04 06:05:12 leatherback kernel: usb 1-4: Creating new data endpoint #88 Jan 04 06:05:12 leatherback kernel: usb 1-4: 2:1: add audio endpoint 0x88 Jan 04 06:05:12 leatherback kernel: usb 1-4: [10] FU [PCM Playback Switch] ch = 4, val = 0/1/1 Jan 04 06:05:12 leatherback kernel: usb 1-4: [10] FU [PCM Playback Switch] ch = 1, val = 0/1/1 Jan 04 06:05:12 leatherback kernel: usb 1-4: [10] FU [PCM Playback Volume] ch = 4, val = -32512/0/256 Jan 04 06:05:12 leatherback kernel: usb 1-4: [10] FU [PCM Playback Volume] ch = 1, val = -32512/0/256 Jan 04 06:05:12 leatherback kernel: usb 1-4: [11] FU [Mic Capture Switch] ch = 4, val = 0/1/1 Jan 04 06:05:12 leatherback kernel: usb 1-4: [11] FU [Mic Capture Switch] ch = 1, val = 0/1/1 Jan 04 06:05:12 leatherback kernel: usb 1-4: [11] FU [Mic Capture Volume] ch = 4, val = -32512/0/256 Jan 04 06:05:12 leatherback kernel: usb 1-4: [11] FU [Mic Capture Volume] ch = 1, val = -32512/0/256 Jan 04 06:05:12 leatherback kernel: usbcore: registered new interface driver snd-usb-audio Jan 04 06:06:07 leatherback kernel: usb 1-4: Open EP 0x8, iface=1:1, idx=0 Jan 04 06:06:07 leatherback kernel: usb 1-4: channels=4, rate=48000, format=S32_LE, period_bytes=96000, periods=4, implicit_fb=1 Jan 04 06:06:07 leatherback kernel: usb 1-4: Open EP 0x88, iface=2:1, idx=0 Jan 04 06:06:07 leatherback kernel: usb 1-4: channels=4, rate=48000, format=S32_LE, period_bytes=96000, periods=4, implicit_fb=0 Jan 04 06:06:07 leatherback kernel: usb 1-4: Setting params for data EP 0x88, pipe 0x40580 Jan 04 06:06:07 leatherback kernel: usb 1-4: Set up 12 URBS, ret=0 Jan 04 06:06:07 leatherback kernel: usb 1-4: Setting params for data EP 0x8, pipe 0x40500 Jan 04 06:06:07 leatherback kernel: usb 1-4: Set up 12 URBS, ret=0 Jan 04 06:06:07 leatherback kernel: usb 1-4: Setting usb interface 2:0 for EP 0x88 Jan 04 06:06:07 leatherback kernel: usb 1-4: 2:1 Set sample rate 48000, clock 40 Jan 04 06:06:07 leatherback kernel: usb 1-4: Setting usb interface 2:1 for EP 0x88 Jan 04 06:06:07 leatherback kernel: usb 1-4: Setting usb interface 1:0 for EP 0x8 Jan 04 06:06:07 leatherback kernel: usb 1-4: Setting usb interface 1:1 for EP 0x8 Jan 04 06:06:07 leatherback kernel: usb 1-4: Starting data EP 0x8 (running 0) Jan 04 06:06:07 leatherback kernel: usb 1-4: 12 URBs submitted for EP 0x8 Jan 04 06:06:07 leatherback kernel: usb 1-4: Starting data EP 0x88 (running 0) Jan 04 06:06:07 leatherback kernel: usb 1-4: 12 URBs submitted for EP 0x88 Jan 04 06:06:07 leatherback kernel: usb 1-4: 1:1 Start Playback PCM Jan 04 06:06:30 leatherback kernel: usb 1-4: Stopping data EP 0x88 (running 1) Jan 04 06:06:30 leatherback kernel: usb 1-4: Stopping data EP 0x8 (running 1) Jan 04 06:06:30 leatherback kernel: usb 1-4: 1:1 Stop Playback PCM Jan 04 06:06:30 leatherback kernel: usb 1-4: Closing EP 0x8 (count 1) Jan 04 06:06:30 leatherback kernel: usb 1-4: Setting usb interface 1:0 for EP 0x8 Jan 04 06:06:30 leatherback kernel: usb 1-4: EP 0x8 closed Jan 04 06:06:30 leatherback kernel: usb 1-4: Closing EP 0x88 (count 1) Jan 04 06:06:30 leatherback kernel: usb 1-4: Setting usb interface 2:0 for EP 0x88 Jan 04 06:06:30 leatherback kernel: usb 1-4: EP 0x88 closed
On Wed, 4 Jan 2023 at 06:09, Michael Ralston michael@ralston.id.au wrote:
On Wed, 4 Jan 2023 at 03:03, Takashi Iwai tiwai@suse.de wrote:
OK, thanks. Then it's not about the USB interface reset. It must be subtle and nasty difference.
Could you apply the change below on the top? It essentially reverts the hw_params/prepare split again.
Very sorry to say this still hasn't fixed the problem :(
I did a diff between the sound/usb directory for 6.0.16 and 6.1.2 and reverted that entire directory.
It is working with that change, so there must be something else.
Michael
On Wed, 4 Jan 2023 at 06:24, Michael Ralston michael@ralston.id.au wrote:
I did a diff between the sound/usb directory for 6.0.16 and 6.1.2 and reverted that entire directory.
It is working with that change, so there must be something else.
Logs below...
Jan 04 06:20:27 leatherback kernel: mc: Linux media interface: v0.10 Jan 04 06:20:27 leatherback kernel: usb 1-3: Found last interface = 1 Jan 04 06:20:27 leatherback kernel: usb 1-4: Set quirk_flags 0x20010 for device 1397:0509 Jan 04 06:20:27 leatherback kernel: usb 1-4: Found last interface = 4 Jan 04 06:20:27 leatherback kernel: usb 1-4: 1:1: added playback implicit_fb sync_ep 88, iface 2:1 Jan 04 06:20:27 leatherback kernel: usb 1-4: 1:1: add audio endpoint 0x8 Jan 04 06:20:27 leatherback kernel: usb 1-4: Creating new data endpoint #8 Jan 04 06:20:27 leatherback kernel: usb 1-4: Creating new data endpoint #88 Jan 04 06:20:27 leatherback kernel: usb 1-4: 1:1 Set sample rate 192000, clock 40 Jan 04 06:20:27 leatherback kernel: usb 1-4: 2:1: add audio endpoint 0x88 Jan 04 06:20:27 leatherback kernel: usb 1-4: 2:1 Set sample rate 192000, clock 40 Jan 04 06:20:27 leatherback kernel: usb 1-4: clock source 41 is not valid, cannot use Jan 04 06:20:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Switch] ch = 4, val = 0/1/1 Jan 04 06:20:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Switch] ch = 1, val = 0/1/1 Jan 04 06:20:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Volume] ch = 4, val = -32512/0/256 Jan 04 06:20:27 leatherback kernel: usb 1-4: [10] FU [PCM Playback Volume] ch = 1, val = -32512/0/256 Jan 04 06:20:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Switch] ch = 4, val = 0/1/1 Jan 04 06:20:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Switch] ch = 1, val = 0/1/1 Jan 04 06:20:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Volume] ch = 4, val = -32512/0/256 Jan 04 06:20:27 leatherback kernel: usb 1-4: [11] FU [Mic Capture Volume] ch = 1, val = -32512/0/256 Jan 04 06:20:27 leatherback kernel: usbcore: registered new interface driver snd-usb-audio Jan 04 06:20:31 leatherback kernel: usb 1-4: Open EP 0x8, iface=1:1, idx=0 Jan 04 06:20:31 leatherback kernel: usb 1-4: channels=4, rate=48000, format=S32_LE, period_bytes=96000, periods=4, implicit_fb=1 Jan 04 06:20:31 leatherback kernel: usb 1-4: Open EP 0x88, iface=2:1, idx=0 Jan 04 06:20:31 leatherback kernel: usb 1-4: channels=4, rate=48000, format=S32_LE, period_bytes=96000, periods=4, implicit_fb=0 Jan 04 06:20:31 leatherback kernel: usb 1-4: Setting usb interface 2:0 for EP 0x88 Jan 04 06:20:31 leatherback kernel: usb 1-4: 2:1 Set sample rate 48000, clock 40 Jan 04 06:20:31 leatherback kernel: usb 1-4: Setting params for data EP 0x88, pipe 0x40580 Jan 04 06:20:31 leatherback kernel: usb 1-4: Set up 12 URBS, ret=0 Jan 04 06:20:31 leatherback kernel: usb 1-4: Setting usb interface 2:1 for EP 0x88 Jan 04 06:20:31 leatherback kernel: usb 1-4: Setting usb interface 1:0 for EP 0x8 Jan 04 06:20:31 leatherback kernel: usb 1-4: Setting params for data EP 0x8, pipe 0x40500 Jan 04 06:20:31 leatherback kernel: usb 1-4: Set up 12 URBS, ret=0 Jan 04 06:20:31 leatherback kernel: usb 1-4: Setting usb interface 1:1 for EP 0x8 Jan 04 06:20:31 leatherback kernel: usb 1-4: Starting data EP 0x8 (running 0) Jan 04 06:20:31 leatherback kernel: usb 1-4: 12 URBs submitted for EP 0x8 Jan 04 06:20:31 leatherback kernel: usb 1-4: Starting data EP 0x88 (running 0) Jan 04 06:20:31 leatherback kernel: usb 1-4: 12 URBs submitted for EP 0x88 Jan 04 06:20:31 leatherback kernel: usb 1-4: 1:1 Start Playback PCM Jan 04 06:20:32 leatherback kernel: usb 1-4: Stopping data EP 0x88 (running 1) Jan 04 06:20:32 leatherback kernel: usb 1-4: Stopping data EP 0x8 (running 1) Jan 04 06:20:32 leatherback kernel: usb 1-4: 1:1 Stop Playback PCM Jan 04 06:20:32 leatherback kernel: usb 1-4: Closing EP 0x8 (count 1) Jan 04 06:20:32 leatherback kernel: usb 1-4: Setting usb interface 1:0 for EP 0x8 Jan 04 06:20:32 leatherback kernel: usb 1-4: EP 0x8 closed Jan 04 06:20:32 leatherback kernel: usb 1-4: Closing EP 0x88 (count 1) Jan 04 06:20:32 leatherback kernel: usb 1-4: Setting usb interface 2:0 for EP 0x88 Jan 04 06:20:32 leatherback kernel: usb 1-4: EP 0x88 closed
On Wed, 4 Jan 2023 at 06:27, Michael Ralston michael@ralston.id.au wrote:
On Wed, 4 Jan 2023 at 06:24, Michael Ralston michael@ralston.id.au wrote:
I did a diff between the sound/usb directory for 6.0.16 and 6.1.2 and reverted that entire directory.
It is working with that change, so there must be something else.
Logs below...
This line from the logs stands out to me as different. Could this mean anything?
Jan 04 06:20:27 leatherback kernel: usb 1-4: clock source 41 is not valid, cannot use
-- Michael
On Tue, 03 Jan 2023 20:29:54 +0100, Michael Ralston wrote:
On Wed, 4 Jan 2023 at 06:27, Michael Ralston michael@ralston.id.au wrote:
On Wed, 4 Jan 2023 at 06:24, Michael Ralston michael@ralston.id.au wrote:
I did a diff between the sound/usb directory for 6.0.16 and 6.1.2 and reverted that entire directory.
It is working with that change, so there must be something else.
Logs below...
This line from the logs stands out to me as different. Could this mean anything?
Jan 04 06:20:27 leatherback kernel: usb 1-4: clock source 41 is not valid, cannot use
This might be due to the commit ac5e2fb425e1121ceef2b9d1b3ffccc195d55707 ALSA: usb-audio: Drop superfluous interface setup at parsing
I believe it's time to check which commit broke things. Assume that the bug is USB audio core changes, the following 8 commits are relevant:
1045f5f1ff0751423aeb65648e5e1abd7a7a8672 9355b60e401d825590d37f04ea873c58efe9b7bf a74f8d0aa902ca494676b79226e0b5a1747b81d4 9902b303b5ade208b58f0dd38a09831813582211 9a737e7f8b371e97eb649904276407cee2c9cf30 2be79d58645465351af5320eb14c70a94724c5ef ac5e2fb425e1121ceef2b9d1b3ffccc195d55707
Could you try to revert from top to bottom one-by-one, and check which one makes things working again? The most suspected one is 2be79d586454 (one before the last, a big change), but who knows...
thanks,
Takashi
On Wed, 4 Jan 2023 at 19:16, Takashi Iwai tiwai@suse.de wrote:
I believe it's time to check which commit broke things. Assume that the bug is USB audio core changes, the following 8 commits are relevant:
Reverting 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 resulted in this compiler error:
sound/usb/endpoint.c: In function 'snd_usb_endpoint_stop': sound/usb/endpoint.c:1672:27: error: 'struct snd_usb_endpoint' has no member named 'need_prepare' 1672 | ep->need_prepare = true; | ^~
I did git annotate on endpoint.c and found line 1672 was added by commit: 3759ae6600e40
Reverting this commit has allowed me to compile a kernel again.
3759ae6600e40 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 9355b60e401d825590d37f04ea873c58efe9b7bf a74f8d0aa902ca494676b79226e0b5a1747b81d4 9902b303b5ade208b58f0dd38a09831813582211 9a737e7f8b371e97eb649904276407cee2c9cf30
I reverted these six commits, testing each one independently, then adding the next on top of the others, and it didn't fix the issue. Then the next commit wouldn't revert cleanly.
CONFLICT (content): Merge conflict in sound/usb/pcm.c error: could not revert 2be79d586454... ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
++<<<<<<< HEAD + again: + if (subs->sync_endpoint) { + ret = snd_usb_endpoint_prepare(chip, subs->sync_endpoint); + if (ret < 0) + goto unlock; + } + + ret = snd_usb_endpoint_prepare(chip, subs->data_endpoint); ++======= + ret = configure_endpoints(chip, subs); ++>>>>>>> parent of 2be79d586454 (ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)) if (ret < 0) goto unlock; - else if (ret > 0) - snd_usb_set_format_quirk(subs, subs->cur_audiofmt); - ret = 0;
Again, I did a git annotate and found I needed to also revert 67fd112b4b040 to get 2be79d58645465351af5320eb14c70a94724c5ef to revert.
This one also didn't fix the issue.
ac5e2fb425e1121ceef2b9d1b3ffccc195d55707 This final revert on top of all the others fixed the issue.
These are the reverts I made: 3759ae6600e40 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 9355b60e401d825590d37f04ea873c58efe9b7bf a74f8d0aa902ca494676b79226e0b5a1747b81d4 9902b303b5ade208b58f0dd38a09831813582211 9a737e7f8b371e97eb649904276407cee2c9cf30 67fd112b4b040 2be79d58645465351af5320eb14c70a94724c5ef ac5e2fb425e1121ceef2b9d1b3ffccc195d55707
-- Michael
On Wed, 04 Jan 2023 15:22:13 +0100, Michael Ralston wrote:
On Wed, 4 Jan 2023 at 19:16, Takashi Iwai tiwai@suse.de wrote:
I believe it's time to check which commit broke things. Assume that the bug is USB audio core changes, the following 8 commits are relevant:
Reverting 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 resulted in this compiler error:
sound/usb/endpoint.c: In function 'snd_usb_endpoint_stop': sound/usb/endpoint.c:1672:27: error: 'struct snd_usb_endpoint' has no member named 'need_prepare' 1672 | ep->need_prepare = true; | ^~
I did git annotate on endpoint.c and found line 1672 was added by commit: 3759ae6600e40
Reverting this commit has allowed me to compile a kernel again.
3759ae6600e40 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 9355b60e401d825590d37f04ea873c58efe9b7bf a74f8d0aa902ca494676b79226e0b5a1747b81d4 9902b303b5ade208b58f0dd38a09831813582211 9a737e7f8b371e97eb649904276407cee2c9cf30
I reverted these six commits, testing each one independently, then adding the next on top of the others, and it didn't fix the issue. Then the next commit wouldn't revert cleanly.
CONFLICT (content): Merge conflict in sound/usb/pcm.c error: could not revert 2be79d586454... ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
++<<<<<<< HEAD
- again:
if (subs->sync_endpoint) {ret = snd_usb_endpoint_prepare(chip, subs->sync_endpoint);if (ret < 0)goto unlock;}ret = snd_usb_endpoint_prepare(chip, subs->data_endpoint);++=======
ret = configure_endpoints(chip, subs);++>>>>>>> parent of 2be79d586454 (ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)) if (ret < 0) goto unlock;
else if (ret > 0)snd_usb_set_format_quirk(subs, subs->cur_audiofmt);ret = 0;Again, I did a git annotate and found I needed to also revert 67fd112b4b040 to get 2be79d58645465351af5320eb14c70a94724c5ef to revert.
This one also didn't fix the issue.
ac5e2fb425e1121ceef2b9d1b3ffccc195d55707 This final revert on top of all the others fixed the issue.
These are the reverts I made: 3759ae6600e40 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 9355b60e401d825590d37f04ea873c58efe9b7bf a74f8d0aa902ca494676b79226e0b5a1747b81d4 9902b303b5ade208b58f0dd38a09831813582211 9a737e7f8b371e97eb649904276407cee2c9cf30 67fd112b4b040 2be79d58645465351af5320eb14c70a94724c5ef ac5e2fb425e1121ceef2b9d1b3ffccc195d55707
Oh, did you test with 6.2-rc? I checked the reverts only on top of the 6.1.0. From there, you can revert all mentioned commits cleanly and should build.
In anyway, do I understand correctly that the bug still persists at the revert of the commit 2be79d58645465351af5320eb14c70a94724c5ef, and it's fixed by the revert of ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
If so, what happens if you revert only ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
Takashi
On Thu, 5 Jan 2023 at 01:42, Takashi Iwai tiwai@suse.de wrote: fb425e1121ceef2b9d1b3ffccc195d55707
Oh, did you test with 6.2-rc? I checked the reverts only on top of the 6.1.0. From there, you can revert all mentioned commits cleanly and should build.
I was basing everything on 6.1.2
In anyway, do I understand correctly that the bug still persists at the revert of the commit 2be79d58645465351af5320eb14c70a94724c5ef, and it's fixed by the revert of ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
Yes that is correct.
If so, what happens if you revert only ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
I just tested this, and that also fixes the issue.
-- Michael
On Wed, 04 Jan 2023 15:47:29 +0100, Michael Ralston wrote:
On Thu, 5 Jan 2023 at 01:42, Takashi Iwai tiwai@suse.de wrote: fb425e1121ceef2b9d1b3ffccc195d55707
Oh, did you test with 6.2-rc? I checked the reverts only on top of the 6.1.0. From there, you can revert all mentioned commits cleanly and should build.
I was basing everything on 6.1.2
In anyway, do I understand correctly that the bug still persists at the revert of the commit 2be79d58645465351af5320eb14c70a94724c5ef, and it's fixed by the revert of ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
Yes that is correct.
If so, what happens if you revert only ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
I just tested this, and that also fixes the issue.
OK, thanks for confirmation. Then we should revert this, as it was meant only as a minor optimization.
Takashi
On Thu, 5 Jan 2023 at 01:54, Takashi Iwai tiwai@suse.de wrote:
OK, thanks for confirmation. Then we should revert this, as it was meant only as a minor optimization.
I'm glad I could help find the issue! Keep up the good work.
-- Michael
On Wed, 04 Jan 2023 15:56:15 +0100, Michael Ralston wrote:
On Thu, 5 Jan 2023 at 01:54, Takashi Iwai tiwai@suse.de wrote:
OK, thanks for confirmation. Then we should revert this, as it was meant only as a minor optimization.
I'm glad I could help find the issue! Keep up the good work.
And I thank you for your patient testing!
Takashi
linux-stable-mirror@lists.linaro.org
-
Michael Ralston -
Takashi Iwai -
Thorsten Leemhuis