Bug 215079 - No more sound after kernel update
Summary: No more sound after kernel update
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-19 22:41 UTC by Anthony Bourguignon
Modified: 2022-05-24 15:27 UTC (History)
8 users (show)

See Also:
Kernel Version: 5.11+
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
before switching to pro-audio profile (118.31 KB, text/plain)
2021-11-20 13:38 UTC, Anthony Bourguignon
Details
after switching to pro-audio profile (118.31 KB, text/plain)
2021-11-20 13:39 UTC, Anthony Bourguignon
Details
after switching back to multichannel profile (118.31 KB, text/plain)
2021-11-20 13:39 UTC, Anthony Bourguignon
Details
pactl list cards showing no ports (1.88 KB, text/plain)
2021-11-20 13:47 UTC, Anthony Bourguignon
Details
gnome control center showing no outputs with pro-audio (68.78 KB, image/png)
2021-11-20 13:49 UTC, Anthony Bourguignon
Details
dmesg on a working kernel with snd_usb_audio.dyndbg=+p (2.79 KB, text/plain)
2021-11-26 08:35 UTC, Anthony Bourguignon
Details
dmesg on a non working kernel with snd_usb_audio.dyndbg=+p (9.58 KB, text/plain)
2021-11-26 08:35 UTC, Anthony Bourguignon
Details
alsa-info (184.85 KB, text/plain)
2022-02-15 15:00 UTC, Craig McLure
Details
alsa-info-5.10 (183.25 KB, text/plain)
2022-02-15 15:18 UTC, Craig McLure
Details
diff state-5.10.txt state-5.16.txt (1.07 KB, text/plain)
2022-03-22 01:47 UTC, Craig McLure
Details
stream0 5.10 (471 bytes, text/plain)
2022-04-26 13:40 UTC, Anthony Bourguignon
Details
stream0 5.18 (595 bytes, text/plain)
2022-04-26 13:40 UTC, Anthony Bourguignon
Details
stream0 with patched 5.18 (485 bytes, text/plain)
2022-04-27 11:30 UTC, Anthony Bourguignon
Details
usbcapture 5.10 (43 bytes, text/plain)
2022-04-28 15:40 UTC, Anthony Bourguignon
Details
usbcapture 5.18 without patch (43 bytes, text/plain)
2022-04-28 15:41 UTC, Anthony Bourguignon
Details
usbcapture 5.18 patched (43 bytes, text/plain)
2022-04-28 15:42 UTC, Anthony Bourguignon
Details
usbcapture 5.18 without patch with arecord (43 bytes, text/plain)
2022-04-29 08:32 UTC, Anthony Bourguignon
Details
usbcapture 5.18-rc5 patched and reverted (43 bytes, text/plain)
2022-05-02 10:27 UTC, Anthony Bourguignon
Details
speaker-test capture (2.64 MB, audio/wav)
2022-05-05 05:32 UTC, Craig McLure
Details
Revert altno interface setttings in stream.c (596 bytes, patch)
2022-05-05 08:25 UTC, Jaroslav Kysela
Details | Diff
usbcapture 5.18-rc5 patched and reverted again (43 bytes, text/plain)
2022-05-05 14:34 UTC, Anthony Bourguignon
Details
Modify altno settings (#2) (1.45 KB, patch)
2022-05-08 12:48 UTC, Jaroslav Kysela
Details | Diff
Modify altno settings (#3) (1.45 KB, patch)
2022-05-10 14:49 UTC, Jaroslav Kysela
Details | Diff
usbcapture 5.18-rc6 implicit and ep2 patches (43 bytes, text/plain)
2022-05-10 16:03 UTC, Anthony Bourguignon
Details
Test fix for clock refecounting (6.81 KB, patch)
2022-05-12 06:21 UTC, Takashi Iwai
Details | Diff
module crash with 5.18-rc6 and 0001-ALSA-usb-audio-Refcount-multiple-accesses-on-the-sin patch (4.65 KB, text/plain)
2022-05-12 07:42 UTC, Anthony Bourguignon
Details
Test fix for clock refecounting (v2) (7.26 KB, patch)
2022-05-12 07:45 UTC, Takashi Iwai
Details | Diff
Test fix for clock refecounting (v3) (7.56 KB, patch)
2022-05-12 09:15 UTC, Takashi Iwai
Details | Diff
Modify altno settings (#4) (1.82 KB, patch)
2022-05-12 09:47 UTC, Jaroslav Kysela
Details | Diff
usbcapture 5.18-rc6 implicit and ep3 patches (43 bytes, text/plain)
2022-05-12 10:51 UTC, Anthony Bourguignon
Details
Initialize sync_ep (implicit feedback stream) as first (966 bytes, patch)
2022-05-13 09:45 UTC, Jaroslav Kysela
Details | Diff
Initialize sync_ep (implicit feedback stream) as first + delay (962 bytes, patch)
2022-05-13 13:27 UTC, Jaroslav Kysela
Details | Diff
output to comment#91 patch (185.52 KB, application/gzip)
2022-05-13 16:52 UTC, Craig McLure
Details
usbcapture 5.18-rc7 no patch (43 bytes, text/plain)
2022-05-16 15:29 UTC, Anthony Bourguignon
Details
Another test fix (1.77 KB, patch)
2022-05-19 07:08 UTC, Takashi Iwai
Details | Diff
Another test fix (revised) (2.09 KB, patch)
2022-05-19 09:01 UTC, Takashi Iwai
Details | Diff
A workaround patch for interface reset at clock change (706 bytes, patch)
2022-05-20 12:00 UTC, Takashi Iwai
Details | Diff
Patch fixing the GoXLR Output (2.38 KB, patch)
2022-05-23 11:35 UTC, Craig McLure
Details | Diff
Patch fixing the GoXLR Output (762 bytes, patch)
2022-05-23 12:40 UTC, Craig McLure
Details | Diff
Call snd_usb_endpoint_configure() after sync_pending_stops() for sync_endpoint (901 bytes, patch)
2022-05-23 13:03 UTC, Jaroslav Kysela
Details | Diff
Git patch with fix (1.52 KB, patch)
2022-05-23 22:30 UTC, Craig McLure
Details | Diff

Description Anthony Bourguignon 2021-11-19 22:41:48 UTC
Hi,

I’ve been running with an issue for quite some time. Because of the freeze of bullseye, we didn’t get a kernel update on Debian sid for quite some time. So I stayed with a kernel 5.10. Then, the update came and I switched to a 5.14 kernel. But I didn’t have sound anymore. The device is still present, but nothing comes out of the headphones. If I reboot, same hardware, same installation, but I choose the 5.10 kernel, the sound is back, without changing anything else. I installed a 5.15 kernel from experimental and still no sound.

I tried to change the profile with pavucontrol, without success. With the kernel 5.14, when I do so, I have the following messages in syslog :

Nov 19 18:13:31 moss pipewire[1606]: spa.alsa: Broken configuration: no configurations available: Argument invalide
Nov 19 18:13:31 moss pipewire[1606]: spa.alsa: Broken configuration: no configurations available: Argument invalide
Nov 19 18:13:31 moss pipewire[1606]: spa.alsa: Broken configuration for playback: no configurations available: Argument invalide
Nov 19 18:13:31 moss pipewire[1606]: pw.node: (alsa_input.usb-TC-Helicon_GoXLR-00.multichannel-input-75) suspended -> error (Start error: Argument invalide)
Nov 19 18:13:31 moss pipewire[1606]: spa.alsa: Broken configuration: no configurations available: Argument invalide
Nov 19 18:13:31 moss pipewire[1606]: spa.alsa: Broken configuration: no configurations available: Argument invalide
Nov 19 18:13:31 moss pipewire[1606]: spa.alsa: Broken configuration for playback: no configurations available: Argument invalide

I also tried a live Fedora (kernel 5.14) and a live Ubuntu (5.13), they have the same issue : no sound on my main device (a usb mixer). So it seems related to how is handled the device with kernel between 5.10 and 5.13.

During my tests, I also stopped pipewire completely to play audio directly to the hardware (with speaker-test and aplay). With 5.10, it’s ok. With 5.14, the processes seem ok but no sound is played.

Can you please help ?
Comment 1 Anthony Bourguignon 2021-11-20 13:38:54 UTC
Created attachment 299651 [details]
before switching to pro-audio profile
Comment 2 Anthony Bourguignon 2021-11-20 13:39:27 UTC
Created attachment 299653 [details]
after switching to pro-audio profile
Comment 3 Anthony Bourguignon 2021-11-20 13:39:57 UTC
Created attachment 299655 [details]
after switching back to multichannel profile
Comment 4 Anthony Bourguignon 2021-11-20 13:45:34 UTC
I made a few tests with the 5.10 kernel. It seems there is an issue with the pro-audio profile. If I boot my computer and the multichannel profile is selected, the sound is working. Then, if I choose the pro-audio profile in pavucontrol, I don’t have sound anymore and gnome-control-center shows no output. If I switch back to the multichannel profile, the outputs are back but there is no sound when I test them in gnome control center. I have to switch several times between profiles (but not pro-audio) to make the sound work again. That’s really strange. What is this pro-audio profile ? Did something change about it between kernel 5.10 and 5.13 ?

Thank you
Comment 5 Anthony Bourguignon 2021-11-20 13:47:22 UTC
Created attachment 299657 [details]
pactl list cards showing no ports
Comment 6 Anthony Bourguignon 2021-11-20 13:49:21 UTC
Created attachment 299659 [details]
gnome control center showing no outputs with pro-audio
Comment 7 Anthony Bourguignon 2021-11-20 14:47:07 UTC
I tried with another computer, and still no sound with a kernel 5.14. When I activate a ucm2 profile for this device (from here : https://github.com/alsa-project/alsa-ucm-conf/issues/121, which is working with 5.10), spa-acp-tool shows this message :

snd_pcm_hw_params_any failed
unable to initialize slave
Error opening PCM device _ucm0001.goxlr_sample_input:GoXLR: Invalid argument
Comment 8 Anthony Bourguignon 2021-11-25 18:37:56 UTC
Hello,

So I did a bisect on the kernel repository, and I found the commit responsible : bf6313a0ff766925462e97b4e733d5952de02367 ( https://github.com/torvalds/linux/commit/bf6313a0ff766925462e97b4e733d5952de02367 ).

Here is the result from the bisect :
git bisect bad bf6313a0ff766925462e97b4e733d5952de02367
# first bad commit: [bf6313a0ff766925462e97b4e733d5952de02367] ALSA: usb-audio: Refactor endpoint management

Do you have an idea why this commit is breaking my sound ? Can we do something about it ?
Comment 9 Anthony Bourguignon 2021-11-26 08:34:00 UTC
Hi,

I saw this issue : https://bugzilla.kernel.org/show_bug.cgi?id=214105 which looked a lot like mine. So I compiled a 5.16-rc2 kernel, adding

DEVICE_FLG(0x1220, 0x8fe0, /* TC-Helicon GoXLR Regular */
  QUIRK_FLAG_SET_IFACE_FIRST),

below the same quirk for the Walkman NW-A45. But still not sound on this version with the patch.
Comment 10 Anthony Bourguignon 2021-11-26 08:35:16 UTC
Created attachment 299727 [details]
dmesg on a working kernel with snd_usb_audio.dyndbg=+p
Comment 11 Anthony Bourguignon 2021-11-26 08:35:41 UTC
Created attachment 299729 [details]
dmesg on a non working kernel with snd_usb_audio.dyndbg=+p
Comment 12 Anthony Bourguignon 2022-01-14 10:47:52 UTC
Hello,

I’m still having this issue which prevents me from upgrading my kernel. I tried more recent kernels and the problem is still here. For my tests, I use a virtual machine with only the bare minimum (only alsa, no audio server) :
  speaker-test -D hw:CARD=GoXLR,DEV=0 -c 10 -F S32_LE -r 48000
With a kernel 5.10, I can hear the noise in my headphones. If I upgrade to something after, everything seems ok, but there is no sound at all with the same command.

Can you please give some help ?
Comment 13 Takashi Iwai 2022-01-14 16:52:46 UTC
Try different quirk bits.  There are various workarounds, and you can set it up via snd_usb_audio quirk_flags option (that's a new option for the recent kernels), which works without recompiling the kernel.

Note that the option is an array, so if you have multiple devices, it has to be specified in the right position.
Comment 14 Thomas Luquet 2022-01-15 09:22:12 UTC
Hi, 
I have no sound too when i try to play stuff on the goXlr.

I have time, if i can help in anyway it, contact me.

On kernel 5.14.21 (Manjaro)
$ speaker-test -D hw:CARD=GoXLR,DEV=0 -c 10 -F S32_LE -r 48000

speaker-test 1.2.6

Playback device is hw:CARD=GoXLR,DEV=0
Stream parameters are 48000Hz, S32_LE, 10 channels
Using 16 octaves of pink noise
Playback open error: -16,Device or resource busy


On PC card list :
Card #2
	Name: alsa_card.usb-TC-Helicon_GoXLR-00
	Driver: module-alsa-card.c
	Owner Module: 8
	Properties:
		alsa.card = "5"
		alsa.card_name = "GoXLR"
		alsa.long_card_name = "TC-Helicon GoXLR at usb-0000:09:00.3-2.1.2, high speed"
		alsa.driver_name = "snd_usb_audio"
		device.bus_path = "pci-0000:09:00.3-usb-0:2.1.2:1.0"
		sysfs.path = "/devices/pci0000:00/0000:00:08.1/0000:09:00.3/usb5/5-2/5-2.1/5-2.1.2/5-2.1.2:1.0/sound/card5"
		udev.id = "usb-TC-Helicon_GoXLR-00"
		device.bus = "usb"
		device.vendor.id = "1220"
		device.vendor.name = "TC Electronic"
		device.product.id = "8fe0"
		device.product.name = "GoXLR"
		device.serial = "TC-Helicon_GoXLR"
		device.string = "5"
		device.description = "GoXLR"
		module-udev-detect.discovered = "1"
		device.icon_name = "audio-card-usb"
	Profiles:
		HiFi: Default Alsa Profile (sinks: 5, sources: 3, priority: 8000, available: yes)
		off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
	Active Profile: HiFi
	Ports:
		[Out] Line3: Sample (type: Line, priority: 500, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
		[Out] Headphones: Chat (type: Headphones, priority: 200, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
		[Out] Line2: Music (type: Line, priority: 400, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
		[Out] Line1: Game (type: Line, priority: 300, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
		[Out] Speaker: System (type: Speaker, priority: 100, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
		[In] Line5: Sample (type: Line, priority: 300, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
		[In] Headset: Chat Mic (type: Headset, priority: 100, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
		[In] Line4: Broadcast Stream Mix (type: Line, priority: 200, latency offset: 0 usec, availability unknown)
			Part of profile(s): HiFi
Comment 15 Anthony Bourguignon 2022-01-16 11:34:08 UTC
(In reply to Takashi Iwai from comment #13)
> Try different quirk bits.  There are various workarounds, and you can set it
> up via snd_usb_audio quirk_flags option (that's a new option for the recent
> kernels), which works without recompiling the kernel.
> 
> Note that the option is an array, so if you have multiple devices, it has to
> be specified in the right position.

Hi and thanks for the hint,

So I did create a /etc/modprobe.d/goxlr.conf file and put that content :
  options snd_usb_audio quirk_flags=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
I then changed each 0 to a 1. Is that the correct way to do it ?

I only have on sound interface on my VM for the test. I tried each bit (so each quirk), but none of them worked. My interface is still mute. If I boot back to a 5.10 kernel, speaker-test works as expected.

To be more precise, it seems that some people do have audio working with a kernel newer than 5.10. Is it possible that it’s an issue between the commit bf6313a0ff766925462e97b4e733d5952de02367 and the usb stack ?

I tried with 2 different computers with different chipsets (one is intel based, the other is amd).
Comment 16 Craig McLure 2022-02-05 02:03:45 UTC
Adding some feedback here, I'm seeing the same results as Anthony, I also cannot get speaker-test to work with the GoXLR, none of the tested channels will produce an output, despite iterating over all of them.

If I run up PulseAudio and connect to the channels directly via jack I *AM* able to abstract the audio as expected.

Commands to output audio:

jack_control dps device hw:GoXLR
jack_control dps period 512
jack_control dps rate 48000
jack_control dps nperiods 3

pactl load-module module-jack-sink channels=2 sink_properties=device.description=GoXLR_System client_name=GoXLR_Sink_System connect=no

jack_connect system:playback_1 GoXLR_Sink_System:front-left
jack_connect system:playback_2 GoXLR_Sink_System:front-right

This implies the audio is working, but something is happening which prevents speaker-test and the UCM profiles from correctly configuring.

Let me know if I can provide any additional information.
Comment 17 Craig McLure 2022-02-15 15:00:51 UTC
Created attachment 300468 [details]
alsa-info

Attaching alsa-info.sh output.
Comment 18 Craig McLure 2022-02-15 15:18:47 UTC
Created attachment 300469 [details]
alsa-info-5.10

Attached alsa-info.sh from a working 5.10 kernel for possible comparison.
Comment 19 Thomas Luquet 2022-02-22 20:07:08 UTC
You can find my alsa-infos.sh here :
http://alsa-project.org/db/?f=1874a6348bb3182fae250e7c81e2b770c1b084ad
Comment 20 Anthony Bourguignon 2022-03-21 08:33:21 UTC
Hello,

Can we please have some help from the kernel team ? We are stuck with the 5.10 kernel because of this bug.

Thanks
Comment 21 Jaroslav Kysela 2022-03-21 09:09:14 UTC
Please, try to isolate the issue with the plain ALSA tools at first (speaker-test or aplay) like in comment#12. The speaker-test or aplay must work with the direct device (hw:#), otherwise we cannot move forward.

The quirk_flags option is a bitmask - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/usb/usbaudio.h?id=f443e374ae131c168a065ea1748feac6b2e76613#n127 . So quirk_flags=2064 is equal to QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_IFACE_DELAY for example (for the first USB sound card). quirk_flags=0,2064 - second USB sound card.

There are also other USB audio kernel module options (autoclock,lowlatency,delayed_register,implicit_fb) to configure the USB driver.

It may be helpful to check the control settings (alsactl -f state.txt store / restore) - you can do a diff between 5.10 and later kernels.
Comment 22 Craig McLure 2022-03-22 01:47:46 UTC
Created attachment 300596 [details]
diff state-5.10.txt state-5.16.txt

Thanks for the clarification on the quirk_flags behaviour, I tested all 17 of them individually but still wasn't able to get any sound from speaker-test (as before, it iterated over all the audio channels, but there was no output). I also tried the other module options to no avail.

As requested, I performed a alsactl -f state-5.xx.txt store on both 5.10 and 5.16, and I've attached the diff.
Comment 23 Thomas Luquet 2022-03-27 15:01:18 UTC
hello, I just want to send some love to the person who can fix this bug. <3
Comment 24 Craig McLure 2022-04-23 00:10:49 UTC
Is there any additional information we can provide to help track down this issue?

Prior to the 5.11 changes (and the bisect mentioned above) the GoXLR device did have issues with intermittent cutouts of audio using speaker-test, they seemed relatively consistent every second or so.. As mentioned in one of my previous comments the only way we've been able to successfully pull audio from the device since that change is via jack using the ALSA plugin (the skipping disappeared with the 5.11 changes under those conditions)..

It's a little odd, because it does imply that ALSA is providing working PCM stream out to Jack when it requests them, but at the same time isn't able to provide working channels to the speaker-test command or UCM.

Unfortunately it's been a while since I've worked with C, and my understanding of the USB audio protocol is certainly lacking, I've been trying to poke at stuff but haven't found anything obvious which could be the cause. I've tried the quirks, but none of them seem to have a positive effect.

I'm very much happy to help with trying to resolve this, and having the device working correctly under linux (for the GoXLR on Linux community, having the basic ALSA and UCM configurations working cleanly would be great!), so if any advice could be provided to allow me to work closer with this, please let me know.

Thanks,
Craig McLure
Comment 25 Takashi Iwai 2022-04-26 08:29:57 UTC
Try the very latest kernel, which received a few important USB-audio fixes.
Comment 26 Anthony Bourguignon 2022-04-26 12:11:40 UTC
(In reply to Takashi Iwai from comment #25)
> Try the very latest kernel, which received a few important USB-audio fixes.

Hello,

I’ve just tested 5.18.0-rc4 and still no audio with the GoXLR.

What do you need to help us on this matter ? Would it help if you had the device ?
Comment 27 Takashi Iwai 2022-04-26 12:23:53 UTC
If the playback worked in the old kernel with ALSA native tool (aplay with -Dplughw:xxx option), check the exact PCM parameter and the interface/altset shown in stream[0-9] in /proc/asound/carrd*.

Then with the latest kernel, check in the same way and see whether the parameter or the iface/altset differs.  That's the first step.

At next, as already mentioned, try different quirk bits.  Make sure that you really apply the quirk bit to the corresponding device.  If you have multiple USB-audio devices, the option will take multiple values for all of those (it's an array).
Comment 28 Takashi Iwai 2022-04-26 12:34:27 UTC
And, if it's about the incorrectly recognized implicit feedback (e.g. it shouldn't have been enabled), you can disable it in the table playback_implicit_fb_quirks[] in sound/usb/implicit.c.
Comment 29 Anthony Bourguignon 2022-04-26 13:40:03 UTC
Created attachment 300806 [details]
stream0 5.10
Comment 30 Anthony Bourguignon 2022-04-26 13:40:22 UTC
Created attachment 300807 [details]
stream0 5.18
Comment 31 Anthony Bourguignon 2022-04-26 13:46:53 UTC
Hi back,

I’ve uploaded the stream0 file, under 5.10 (working sound) and 5.18 (no sound) kernel versions.

I can try to test with the playback_implicit_fb_quirks table. But can you be more explicit please ? Should I put it with a IMPLICIT_FB_GENERIC_DEV function, or the IMPLICIT_FB_FIXED_DEV one (in that case, what are the parameters ep and ifnum ?) or something else ?

Thanks
Comment 32 Takashi Iwai 2022-04-26 14:18:19 UTC
No, rather disabling the implicit fb with IMPLICIT_FB_SKIP_DEV().
That is, something like below (suppose the id is 1220:8fe0):

--- a/sound/usb/implicit.c
+++ b/sound/usb/implicit.c
@@ -64,6 +64,9 @@ static const struct snd_usb_implicit_fb_match playback_implicit_fb_quirks[] = {
 	IMPLICIT_FB_FIXED_DEV(0x2466, 0x8003, 0x86, 2), /* Fractal Audio Axe-Fx II */
 	IMPLICIT_FB_FIXED_DEV(0x0499, 0x172a, 0x86, 2), /* Yamaha MODX */
 
+	/* Disable implicit fb */
+	IMPLICIT_FB_SKIP_DEV(0x1220, 0x8fe0),	/* TC Electronic GoXLR */
+
 	/* Special matching */
 	{ .id = USB_ID(0x07fd, 0x0004), .iface_class = USB_CLASS_AUDIO,
 	  .type = IMPLICIT_FB_NONE },		/* MicroBook IIc */
Comment 33 Anthony Bourguignon 2022-04-26 14:47:45 UTC
It does work ! Thanks !

Here is a more complete patch, which handle both the regular and mini versions :

--- implicit.c	2022-04-26 16:28:52.000000000 +0200
+++ implicit.c	2022-04-26 16:32:15.883640585 +0200
@@ -64,6 +64,10 @@ static const struct snd_usb_implicit_fb_
 	IMPLICIT_FB_FIXED_DEV(0x2466, 0x8003, 0x86, 2), /* Fractal Audio Axe-Fx II */
 	IMPLICIT_FB_FIXED_DEV(0x0499, 0x172a, 0x86, 2), /* Yamaha MODX */
 
+	/* Disable implicit fb */
+	IMPLICIT_FB_SKIP_DEV(0x1220, 0x8fe0), /* TC-Helicon GoXLR Regular */
+	IMPLICIT_FB_SKIP_DEV(0x1220, 0x8fe4), /* TC-Helicon GoXLR Mini */
+
 	/* Special matching */
 	{ .id = USB_ID(0x07fd, 0x0004), .iface_class = USB_CLASS_AUDIO,
 	  .type = IMPLICIT_FB_NONE },		/* MicroBook IIc */

Now, the issue is that the stutters are back : https://bugzilla.kernel.org/show_bug.cgi?id=211211 . Any luck to have both the sound working and not having the stutters ?
Comment 34 Takashi Iwai 2022-04-26 15:04:14 UTC
So what actually didn't work with the latest 5.18-rc4?  The situation must have changed, and I need more details about the errors.

IIUC, you still didn't get the proper sound output with aplay -Dplughw (unless patched for disabling implicit fb)?
Comment 35 Anthony Bourguignon 2022-04-26 15:17:36 UTC
Sorry if I wasn’t clear. Here are the actual status :

kernel 5.18-rc4 : no sound at all
kernel 5.18-rc4 with the IMPLICIT_FB_SKIP_DEV patch : the sound output is ok but there are stutters, like reported in the 211211 bug.
Comment 36 Takashi Iwai 2022-04-26 15:25:42 UTC
"No sound at all" -- it means that the playback runs without errors but no actual output (i.e. the data is processed)?  Or does it stall?

If the playback runs but no sound, what happens if you start recording at first with the patched kernel, then run aplay in parallel afterwards?  This will be in a similar situation like the implicit feedback.
Comment 37 Anthony Bourguignon 2022-04-26 15:39:25 UTC
No sound = the playback runs, speaker-test acts as if everything was fine, but there is no sound in my headphones. But it doesn’t hang at all. Everything looks like it is ok.

What do you mean by start recording ? Do you have an exemple ?

For your information, some people managed to have sound working with 5.11 and after. But they use Jack. If they test with speaker-test, no output, but after jack is configured, apps (using jack) are working ok.
Comment 38 Takashi Iwai 2022-04-26 15:45:04 UTC
Run arecord at first:
  % arecord -Dplughw:XXX -vv -fS32_LE -c23 -r48000 -vv foo.wav

While recording, run speaker-test on another terminal:
  % speaker-test -Dplughw:XXX -r48000 -FS32_LE -c10 -tp
Comment 39 Takashi Iwai 2022-04-26 15:46:45 UTC
(In reply to Anthony Bourguignon from comment #37)
> For your information, some people managed to have sound working with 5.11
> and after. But they use Jack. If they test with speaker-test, no output, but
> after jack is configured, apps (using jack) are working ok.

Can you confirm that the playback with JACK works without modification on your machine?
Comment 40 Craig McLure 2022-04-26 21:49:58 UTC
I've done some testing on 5.18-rc4, arecord -> speaker-test on a stock kernel (suggested above) works flawlessly, sound it output and there's no skipping present. I also tested this on 5.16 and it worked flawlessly there as well.

I applied the patch above for IMPLICIT_FB_SKIP_DEV on 5.18rc4 and while audio works, I also experience the skipping during a speaker-test
Comment 41 Anthony Bourguignon 2022-04-27 08:47:06 UTC
I’ve tested it too with a 5.17 kernel :

- speaker-test only : no sound
- launch arecord and then speaker-test : sound is ok
- launch arecord, then speaker-test and stop arecord : sound is ok
- relaunch speaker-test without arecord : no sound
Comment 42 Jaroslav Kysela 2022-04-27 11:23:08 UTC
Could you attach the stream0 contents from procfs (/proc/asound/card*) when the IMPLICIT_FB_SKIP_DEV patch is applied ?
Comment 43 Anthony Bourguignon 2022-04-27 11:30:00 UTC
Created attachment 300820 [details]
stream0 with patched 5.18
Comment 44 Jaroslav Kysela 2022-04-27 11:34:04 UTC
Could you try to turn off lowlatency using the kernel module parameter? (modinfo snd-usb-audio | grep lowlatency)
Comment 45 Anthony Bourguignon 2022-04-27 13:12:02 UTC
Kernel 5.18-rc4 with the IMPLICIT_FB_SKIP_DEV patch and lowlatency parameter to no, there is sound but the stutters are present.
Comment 46 Jaroslav Kysela 2022-04-27 13:48:00 UTC
Thanks. Another thing which we can try is to compare the packets on the USB bus between 5.10 and recent kernels using usbmon: https://fedoraproject.org/wiki/Usbmon . It may help us to identify the difference. The speaker-test may be killed after 2 seconds or so to reduce the capture file size.
Comment 47 Anthony Bourguignon 2022-04-28 15:40:04 UTC
Created attachment 300841 [details]
usbcapture 5.10
Comment 48 Anthony Bourguignon 2022-04-28 15:41:26 UTC
Created attachment 300842 [details]
usbcapture 5.18 without patch
Comment 49 Anthony Bourguignon 2022-04-28 15:42:06 UTC
Created attachment 300843 [details]
usbcapture 5.18 patched
Comment 50 Anthony Bourguignon 2022-04-28 15:44:42 UTC
Here are the 3 usb captures. One with 5.10 (sound working), one with 5.18 with the IMPLICIT_FB_SKIP_DEV patch (sound working) and the last one with 5.18 without the patch (no sound).

As you’ll probably see, the 5.18 no patch is waaaaay bigger than the 2 others, despite the fact I run it approximately the same time. Seems kinda strange.
Comment 51 Jaroslav Kysela 2022-04-28 19:20:26 UTC
The difference in the start sequence (5.10 -> patched kernel):

--- o.txt	2022-04-28 21:17:19.490193039 +0200
+++ p.txt	2022-04-28 21:14:06.038786111 +0200
@@ -1,11 +1,5 @@
       bmRequestType: 0xa1
       bRequest: 1
  -    wValue: 0x0100
  -    wIndex: 10240 (0x2800)
  -    wLength: 1
  -
  -    bmRequestType: 0xa1
  -    bRequest: 1
       wValue: 0x0200
       wIndex: 10496 (0x2900)
       wLength: 1
  @@ -34,3 +28,9 @@
       wValue: 0x0200
       wIndex: 10496 (0x2900)
       wLength: 1
  +
  +    bmRequestType: 0x01
  +    bRequest: SET INTERFACE (11)
  +    bAlternateSetting: 1
  +    wInterface: 1
  +    wLength: 0

The SET_INTERFACE at the end looks suspicious.

The unpatched kernel uses the capture as the feedback stream, so it should be bigger.
Comment 52 Jaroslav Kysela 2022-04-28 19:28:26 UTC
Note that 5.18 does set alternate settings to 0 before control messages and to 1 just before the isochronous out packets.

5.10 sets alternate settings to 1 before control messages (no change, one time).
Comment 53 Anthony Bourguignon 2022-04-29 08:32:57 UTC
Created attachment 300847 [details]
usbcapture 5.18 without patch with arecord
Comment 54 Anthony Bourguignon 2022-04-29 08:35:19 UTC
(In reply to Jaroslav Kysela from comment #52)
> Note that 5.18 does set alternate settings to 0 before control messages and
> to 1 just before the isochronous out packets.
> 
> 5.10 sets alternate settings to 1 before control messages (no change, one
> time).

Thanks for the follow up, even if I didn’t understand much of your reply.

I’ve just sent another usb capture, with the kernel 5.18-rc4, without any patch, but I’ve launched arecord before speaker-test, so there is an output in my headphones this time, like tested before.

Does it help ?
Comment 55 Jaroslav Kysela 2022-04-29 17:15:30 UTC
I didn't have more time to dig to this problem more yesterday.

Could you try to revert commit c7f902015e1e86117e6cd3dde17d5964d88a9559 ?

   ALSA: usb-audio: Don't set altsetting before initializing sample rate
    
    Setting the active altsetting at changing sample rate seems
    unrecommended.  The host should deselect the altsetting at first
    before that, then select it again.
Comment 56 Jaroslav Kysela 2022-04-29 17:16:46 UTC
Do test only with IMPLICIT_FB_SKIP_DEV patch applied, too.
Comment 57 Anthony Bourguignon 2022-05-02 10:27:32 UTC
Created attachment 300867 [details]
usbcapture 5.18-rc5 patched and reverted
Comment 58 Anthony Bourguignon 2022-05-02 10:28:56 UTC
Hello,

I’ve just tested with a 5.18-rc5 kernel. I applied the IMPLICIT_FB_SKIP_DEV patch on it and reverted c7f902015e1e86117e6cd3d as you asked.

The sound works ok but the stutters are still present.
Comment 59 Anthony Bourguignon 2022-05-02 10:30:11 UTC
There is a stutter in the last usbcapture. I stopped the capture right after the stutter. But I don’t know if that’s visible in the packets.
Comment 60 Craig McLure 2022-05-05 05:32:21 UTC
Created attachment 300881 [details]
speaker-test capture

Just as it might be useful, I've attached an audio capture from a 5.18rc4 kernel with the IMPLICIT_FB_SKIP_DEV patch applied, while it's only a mono capture of all the output channels, it is at least useful for visualisation (I attached a cable between the line-out of the GoXLR to the Line-In of my on-board sound card).

While we've been referring to the issue as a 'stutter' it would be better described as a 'drop', it's a relatively consistent 100ms drop every 2 seconds (give or take a few millis on both times).

As an additional check, I re-tested all the quirk flags with the patch, and none of them had any effect.
Comment 61 Jaroslav Kysela 2022-05-05 08:25:04 UTC
Created attachment 300882 [details]
Revert altno interface setttings in stream.c
Comment 62 Jaroslav Kysela 2022-05-05 08:27:48 UTC
From usb capture in comment#57 I suspect that the revert was not done correctly. Could you apply IMPLICIT_FB_SKIP_DEV patch + patch from comment#61 to the latest kernel and retest? You should see a line with YOYO string in dmesg when the test patch is applied correctly.
Comment 63 Anthony Bourguignon 2022-05-05 14:34:23 UTC
Created attachment 300890 [details]
usbcapture 5.18-rc5 patched and reverted again
Comment 64 Anthony Bourguignon 2022-05-05 14:35:43 UTC
(In reply to Jaroslav Kysela from comment #62)
> From usb capture in comment#57 I suspect that the revert was not done
> correctly. Could you apply IMPLICIT_FB_SKIP_DEV patch + patch from
> comment#61 to the latest kernel and retest? You should see a line with YOYO
> string in dmesg when the test patch is applied correctly.

Done and the audio drops are still present. When I connect the device, I’ve got those messages :

[ 2878.871336] usb 1-3: new high-speed USB device number 3 using xhci_hcd
[ 2879.170046] usb 1-3: New USB device found, idVendor=1220, idProduct=8fe0, bcdDevice= 1.00
[ 2879.170227] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2879.170342] usb 1-3: Product: GoXLR
[ 2879.170438] usb 1-3: Manufacturer: TC-Helicon
[ 2879.205365] mc: Linux media interface: v0.10
[ 2879.233433] usb 1-3: 1:1: add audio endpoint 0x8
[ 2879.233450] usb 1-3: Creating new data endpoint #8
[ 2879.235991] usb 1-3: YOYO - reverted - altno=1
[ 2879.236012] usb 1-3: 1:1 Set sample rate 48000, clock 40
[ 2879.254733] usb 1-3: 2:1: add audio endpoint 0x88
[ 2879.254744] usb 1-3: Creating new data endpoint #88
[ 2879.258249] usb 1-3: YOYO - reverted - altno=1
[ 2879.258267] usb 1-3: 2:1 Set sample rate 48000, clock 40
[ 2879.269212] usbcore: registered new interface driver snd-usb-audio
Comment 65 Jaroslav Kysela 2022-05-08 12:48:19 UTC
Created attachment 300906 [details]
Modify altno settings (#2)
Comment 66 Jaroslav Kysela 2022-05-08 12:49:58 UTC
Please, the test patch from comment#65. Same steps as in comment#62 (IMPLICIT_FB_SKIP_DEV patch + this new patch).
Comment 67 Anthony Bourguignon 2022-05-09 08:34:00 UTC
Hello,

I can’t compile because of the ep patch :

In file included from ./include/linux/device.h:15,
                 from ./include/linux/usb.h:19,
                 from sound/usb/endpoint.c:8:
sound/usb/endpoint.c: In function ‘snd_usb_endpoint_configure’:
sound/usb/endpoint.c:1368:18: error: passing argument 1 of ‘_dev_info’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 1368 |         dev_info(&chip->dev, "YOYO (cfg) %d\n", iface_first);
      |                  ^~~~~~~~~~
      |                  |
      |                  struct usb_device **
./include/linux/dev_printk.h:110:25: note: in definition of macro ‘dev_printk_index_wrap’
  110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
      |                         ^~~
sound/usb/endpoint.c:1368:9: note: in expansion of macro ‘dev_info’
 1368 |         dev_info(&chip->dev, "YOYO (cfg) %d\n", iface_first);
      |         ^~~~~~~~
./include/linux/dev_printk.h:56:37: note: expected ‘const struct device *’ but argument is of type ‘struct usb_device **’
   56 | void _dev_info(const struct device *dev, const char *fmt, ...);
Comment 68 Jaroslav Kysela 2022-05-10 14:49:51 UTC
Created attachment 300917 [details]
Modify altno settings (#3)

Fixed patch in comment#65.
Comment 69 Anthony Bourguignon 2022-05-10 16:03:06 UTC
Created attachment 300919 [details]
usbcapture 5.18-rc6 implicit and ep2 patches
Comment 70 Anthony Bourguignon 2022-05-10 16:05:13 UTC
Hi,

I’ve tested with 5.18-rc6, with the 2 patches (implicit and ep2). When I plugged the device :
[   35.248968] usb 1-3: new high-speed USB device number 3 using xhci_hcd
[   35.546682] usb 1-3: New USB device found, idVendor=1220, idProduct=8fe0, bcdDevice= 1.00
[   35.546750] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   35.546789] usb 1-3: Product: GoXLR
[   35.546811] usb 1-3: Manufacturer: TC-Helicon
[   35.561530] mc: Linux media interface: v0.10
[   35.589101] usb 1-3: 1:1: add audio endpoint 0x8
[   35.589124] usb 1-3: Creating new data endpoint #8
[   35.591646] usb 1-3: YOYO - reverted - altno=1
[   35.591664] usb 1-3: 1:1 Set sample rate 48000, clock 40
[   35.606694] usb 1-3: 2:1: add audio endpoint 0x88
[   35.606707] usb 1-3: Creating new data endpoint #88
[   35.608984] usb 1-3: YOYO - reverted - altno=1
[   35.609004] usb 1-3: 2:1 Set sample rate 48000, clock 40
[   35.619274] usbcore: registered new interface driver snd-usb-audio

When I play a wav file, there are still drops (dmesg output) :
[  156.139457] usb 1-3: Open EP 0x8, iface=1:1, idx=0
[  156.139463] usb 1-3:   channels=10, rate=48000, format=S32_LE, period_bytes=240000, periods=4, implicit_fb=0
[  156.139468] usb 1-3: YOYO (cfg) 1
[  156.139493] usb 1-3: Setting usb interface 1:1 for EP 0x8
[  156.142532] usb 1-3: 1:1 Set sample rate 48000, clock 40
[  156.150400] usb 1-3: Setting params for data EP 0x8, pipe 0x40300
[  156.150441] usb 1-3: Set up 3 URBS, ret=0
[  156.151553] usb 1-3: Starting data EP 0x8 (running 0)
[  156.152023] usb 1-3: 3 URBs submitted for EP 0x8
[  156.152028] usb 1-3: 1:1 Start Playback PCM
[  174.862953] usb 1-3: Stopping data EP 0x8 (running 1)
[  174.863287] usb 1-3: 1:1 Stop Playback PCM
[  174.863380] usb 1-3: Closing EP 0x8 (count 1)
[  174.863382] usb 1-3: Setting usb interface 1:0 for EP 0x8
[  174.883467] usb 1-3: EP 0x8 closed

I’ve captured the usb content as always (tell me if you still need it). There is a drop right before I stopped the capture.
Comment 71 Takashi Iwai 2022-05-12 06:20:42 UTC
A possibly relevant problem is the handling of the shared clock source.
Could you try the patch below?
Comment 72 Takashi Iwai 2022-05-12 06:21:03 UTC
Created attachment 300939 [details]
Test fix for clock refecounting
Comment 73 Anthony Bourguignon 2022-05-12 07:41:24 UTC
I’ve just tested it, kernel 5.18-rc6 with only the 0001-ALSA-usb-audio-Refcount-multiple-accesses-on-the-sin patch. On plug, the dmesg shows :

[   43.597775] usb 1-3: new high-speed USB device number 3 using xhci_hcd
[   43.895090] usb 1-3: New USB device found, idVendor=1220, idProduct=8fe0, bcdDevice= 1.00
[   43.895156] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   43.895195] usb 1-3: Product: GoXLR
[   43.895312] usb 1-3: Manufacturer: TC-Helicon
[   43.926085] mc: Linux media interface: v0.10
[   43.961595] usb 1-3: 1:1: added playback implicit_fb sync_ep 88, iface 2:1
[   43.961600] usb 1-3: 1:1: add audio endpoint 0x8
[   43.961609] usb 1-3: Creating new data endpoint #8
[   43.961611] usb 1-3: Creating new data endpoint #88
[   43.962478] usb 1-3: 1:1 Set sample rate 48000, clock 40
[   43.982321] usb 1-3: 2:1: add audio endpoint 0x88
[   43.984149] usb 1-3: 2:1 Set sample rate 48000, clock 40
[   44.004686] usbcore: registered new interface driver snd-usb-audio

Sadly, when I try aplay, the modules crashes.
Comment 74 Anthony Bourguignon 2022-05-12 07:42:04 UTC
Created attachment 300940 [details]
module crash with 5.18-rc6 and 0001-ALSA-usb-audio-Refcount-multiple-accesses-on-the-sin patch
Comment 75 Takashi Iwai 2022-05-12 07:44:54 UTC
My bad, a missing hunk in the patch.  Now the revised patch attached.
Comment 76 Takashi Iwai 2022-05-12 07:45:20 UTC
Created attachment 300941 [details]
Test fix for clock refecounting (v2)
Comment 77 Anthony Bourguignon 2022-05-12 08:39:24 UTC
Thanks for your fast answer and your help.
So, clock patch alone : there is no sound. implicit patch + clock patch, sound is working but I still have drops.

Do you need the usbcapture ?
Comment 78 Takashi Iwai 2022-05-12 09:15:08 UTC
OK, just to be sure, yet more revised patch (v3) is below.
Comment 79 Takashi Iwai 2022-05-12 09:15:28 UTC
Created attachment 300943 [details]
Test fix for clock refecounting (v3)
Comment 80 Jaroslav Kysela 2022-05-12 09:47:06 UTC
Created attachment 300945 [details]
Modify altno settings (#4)

Another try to align the USB communication to the 5.10 kernel. Inhibit code from 086b957cc17f53f03bae9d2baf930ac51cf68b99 (ALSA: usb-audio: Skip the clock selector inquiry for single connections).
Comment 81 Anthony Bourguignon 2022-05-12 09:57:28 UTC
(In reply to Takashi Iwai from comment #78)
> OK, just to be sure, yet more revised patch (v3) is below.

And drops are still present with this patch.
Comment 82 Jaroslav Kysela 2022-05-12 10:44:11 UTC
Could you test / provide usbcapture for the patch in comment#80 ? Thank you.
Comment 83 Anthony Bourguignon 2022-05-12 10:51:51 UTC
Created attachment 300946 [details]
usbcapture 5.18-rc6 implicit and ep3 patches
Comment 84 Anthony Bourguignon 2022-05-12 10:52:09 UTC
(In reply to Jaroslav Kysela from comment #82)
> Could you test / provide usbcapture for the patch in comment#80 ? Thank you.

Drops with this one too
Comment 85 Jaroslav Kysela 2022-05-12 14:03:23 UTC
With the patch from comment#82, the USB control commands send by the ALSA driver to the hardware are identical now.

After further analysis (comparing dumps from comment#47 and comment#83), the USB descriptors are slightly different:

Feature unit descriptor (kernel 5.10 - length 102, kernel 5.18-rc - length 110), two new logical channels were added (number 24 & 25).

Did you upgrade firmware ? Does 5.10 work with the new firmware ?
Comment 86 Craig McLure 2022-05-13 08:31:00 UTC
Just for clarifications sake, the sound dropping behaviour isn't new, it was present in 5.10 and originally tracked at https://bugzilla.kernel.org/show_bug.cgi?id=211211 

When 5.11 was released the ALSA audio output stopped working completely (so this bug was created), the old bug was closed as obsolete.

The patches noted in comment#32 and comment#33 restore the GoXLR to the same behaviour we had in 5.10, where audio output is present but the dropping is occurring.

So the audio drops aren't a regression but something which has always occurred.

Thanks.
Comment 87 Jaroslav Kysela 2022-05-13 09:45:54 UTC
Created attachment 300949 [details]
Initialize sync_ep (implicit feedback stream) as first
Comment 88 Jaroslav Kysela 2022-05-13 09:47:27 UTC
Thanks for the clarification. I was lost (thinking that 5.10 was ok - no drops).

Could you test patch in comment#87 (without any other patches) with the latest kernel?
Comment 89 Robin Van Cauter 2022-05-13 09:58:39 UTC
Unsure if its useful, but thought it might be noteworthy:

We experienced the same audio drops on this device configured directly through JACK as well on pre-5.11 kernels. Starting from 5.11, JACK started working perfectly without any audio drops.
Comment 90 Craig McLure 2022-05-13 11:16:20 UTC
Tested that patch alone on 5.18rc6, there's no audio output on speaker-test.
Comment 91 Jaroslav Kysela 2022-05-13 13:27:45 UTC
Created attachment 300951 [details]
Initialize sync_ep (implicit feedback stream) as first + delay
Comment 92 Jaroslav Kysela 2022-05-13 13:28:55 UTC
Another path to try with the latest kernel. Please, provide the usbcapture output, if things do not work.
Comment 93 Craig McLure 2022-05-13 16:52:43 UTC
Created attachment 300953 [details]
output to comment#91 patch

Still no output with that patch, although there was a pause prior to speaker-test listing the first channel, usb dump attached.
Comment 94 Anthony Bourguignon 2022-05-16 15:29:56 UTC
Created attachment 300969 [details]
usbcapture 5.18-rc7 no patch

Here is a capture from a 5.18-rc7 with no patch. I started arecord before aplay :
  - arecord -Dplughw:GoXLR -vv -fS32_LE -c23 -r48000 -vv foo.wav
  - aplay -Dplughw:GoXLR -r48000 -c10 whitenoise.wav

That way, sound is working without patch and I didn’t have drops. So it seems that the way that it should be initialized.

Does it help ? You can send other patches or tests if you need to.

Thanks again for your time
Comment 95 Takashi Iwai 2022-05-19 07:07:53 UTC
Below is another test fix.  Can anyone check it?
Comment 96 Takashi Iwai 2022-05-19 07:08:26 UTC
Created attachment 300993 [details]
Another test fix
Comment 97 Takashi Iwai 2022-05-19 09:01:33 UTC
Created attachment 300994 [details]
Another test fix (revised)
Comment 98 Anthony Bourguignon 2022-05-19 16:07:41 UTC
Are you on 5.18-rc7. The patch doesn’t apply :
$ LANG=C git apply ../usb-clock-iface-fix.diff
error: patch failed: sound/usb/endpoint.c:1374
error: sound/usb/endpoint.c: patch does not apply

Do you want me to test this patch alone ? What are you trying to resolve with this patch ? The sound not working or the drops ?
Comment 99 Takashi Iwai 2022-05-20 12:00:06 UTC
The patch was for the latest sound.git tree for-next branch, so some change seems missing in 5.17.x or 5.18-rc.  But it turned out that the patch didn't help for other devices, so please scratch that one.

One still interesting thing to test is the following patch.  It seems helping for a TEAC device, at least.
Comment 100 Takashi Iwai 2022-05-20 12:00:34 UTC
Created attachment 301010 [details]
A workaround patch for interface reset at clock change
Comment 101 Anthony Bourguignon 2022-05-20 12:48:27 UTC
Hi back. I’ve just tested this patch, alone, on a 5.18-rc7 kernel. There is no sound unless I launch arecord before.
Comment 102 Takashi Iwai 2022-05-20 14:38:09 UTC
(In reply to Anthony Bourguignon from comment #101)
> Hi back. I’ve just tested this patch, alone, on a 5.18-rc7 kernel. There is
> no sound unless I launch arecord before.

Hm, the device isn't recognized / set up as the implicit feedback mode?  You can see it in /proc/asound/card*/stream0 file.
If it's in the implicit fb mode, basically the capture stream is already tied and starts together with the playback.

Please check the stream0 content both while (only) playing back and while full-duplex running.
Comment 103 Anthony Bourguignon 2022-05-21 11:22:57 UTC
Here is the content of stream0 with aplay but without arecord (no sound output) :
TC-Helicon GoXLR at usb-0000:02:00.0-3, high speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 280
    Momentary freq = 48000 Hz (0x6.0000)
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 10
    Endpoint: 0x08 (8 OUT) (ASYNC)
    Rates: 48000
    Data packet interval: 125 us
    Bits: 24
    Channel map: FL FR FC LFE RL RR FLC FRC RC SL
    Sync Endpoint: 0x88 (8 IN)
    Sync EP Interface: 2
    Sync EP Altset: 1
    Implicit Feedback Mode: Yes

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 23
    Endpoint: 0x88 (8 IN) (ASYNC)
    Rates: 48000
    Data packet interval: 125 us
    Bits: 24

And the same but with arecord running with aplay (sound output is working) :
TC-Helicon GoXLR at usb-0000:02:00.0-3, high speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 280
    Momentary freq = 48000 Hz (0x6.0000)
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 10
    Endpoint: 0x08 (8 OUT) (ASYNC)
    Rates: 48000
    Data packet interval: 125 us
    Bits: 24
    Channel map: FL FR FC LFE RL RR FLC FRC RC SL
    Sync Endpoint: 0x88 (8 IN)
    Sync EP Interface: 2
    Sync EP Altset: 1
    Implicit Feedback Mode: Yes

Capture:
  Status: Running
    Interface = 2
    Altset = 1
    Packet Size = 644
    Momentary freq = 48000 Hz (0x6.0000)
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 23
    Endpoint: 0x88 (8 IN) (ASYNC)
    Rates: 48000
    Data packet interval: 125 us
    Bits: 24

What do you think ?
Comment 104 Takashi Iwai 2022-05-22 07:13:13 UTC
The proc outputs look as expected, the stream running as implicit fb mode.  So far, I have no idea why it makes difference.

Could you give the kernel messages with debug enabled (e.g. snd_usb_audio.dyndbg=+p boot option) for both playback-only case and arecord-then-aplay case?
Comment 105 Takashi Iwai 2022-05-22 10:22:20 UTC
And, you've already tried QUIRK_FLAG_PLAYBACK_FIRST quirk, right?
Comment 106 Craig McLure 2022-05-23 11:35:32 UTC
Created attachment 301015 [details]
Patch fixing the GoXLR Output

The attached patch fixes the GoXLR audio output under 5.17 and 5.18, audio output works correctly with no dropping.

These probably need some level of cleaning / review (The GoXLR mini will likely need adding too).

Seemingly the sync endpoint needs configuring prior to the data endpoint for output to work (I observed this as a change in behaviour between the 5.10 and 5.11+ logs), however this might be better suited as a quirk? I can't say what level of impact that might have on other devices.

The quirks-table is a strange one, all the values I've set there (with the exception of altset_idx) are as they appear in Anthony's usbcapture, so it's not doing anything particularly special, but is required to work.

Let me know if there's anything else that could use help with testing.
Comment 107 Takashi Iwai 2022-05-23 11:53:21 UTC
Great, thanks for hunting it.
The EP configuration order could be applied globally, I guess.

But the quirk entry is puzzling.  I don't see why this entry is needed at all.
Could you double-check?
Comment 108 Craig McLure 2022-05-23 12:40:25 UTC
Created attachment 301017 [details]
Patch fixing the GoXLR Output

I've double checked, and it's not needed. Adjusted patch attached.
Comment 109 Jaroslav Kysela 2022-05-23 12:54:20 UTC
I'm glad that this issue is finally resolved.

The patch should be recoded to call sync_pending_stops() before the sync_endpoint is reconfigured (need_stop condition).
Comment 110 Jaroslav Kysela 2022-05-23 13:03:49 UTC
Created attachment 301018 [details]
Call snd_usb_endpoint_configure() after sync_pending_stops() for sync_endpoint
Comment 111 Craig McLure 2022-05-23 13:18:07 UTC
Just to confirm, that final patch works fine, thanks.

There's a pretty nasty latency issue (over 300ms) on the audio output, do you want me to open a new issue for that so we can start clean, or should I continue here?
Comment 112 Takashi Iwai 2022-05-23 14:07:19 UTC
Craig, could you resubmit the patch with your sign-off at best, so that it can be merged for 5.19-rc1?

And, please open another bug for the latency issue.
Comment 113 Craig McLure 2022-05-23 22:30:48 UTC
Created attachment 301021 [details]
Git patch with fix

Git patch attached.
Comment 114 Thomas Luquet 2022-05-24 07:14:30 UTC
Thak you so much <3
Comment 115 Anthony Bourguignon 2022-05-24 15:27:45 UTC
I confirm that the patch is a success and working fine. The audio is working, without any audio drop. I don’t have the latency issue, but we talked with Craig and it seems it’s related to pulse (I’m using Pipewire and everything is fine).

Great work everyone !

Note You need to log in before you can comment on or make changes to this bug.