Created attachment 299651 [details]
before switching to pro-audio profile

Created attachment 299653 [details]
after switching to pro-audio profile

Created attachment 299655 [details]
after switching back to multichannel profile

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

Created attachment 299657 [details]
pactl list cards showing no ports

Created attachment 299659 [details]
gnome control center showing no outputs with pro-audio

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

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 ?

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.

Created attachment 299727 [details]
dmesg on a working kernel with snd_usb_audio.dyndbg=+p

Created attachment 299729 [details]
dmesg on a non working kernel with snd_usb_audio.dyndbg=+p

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 ?

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, 
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

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

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.

Created attachment 300468 [details]
alsa-info

Attaching alsa-info.sh output.

Created attachment 300469 [details]
alsa-info-5.10

Attached alsa-info.sh from a working 5.10 kernel for possible comparison.

You can find my alsa-infos.sh here :
http://alsa-project.org/db/?f=1874a6348bb3182fae250e7c81e2b770c1b084ad

Hello,

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

Thanks

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.

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.

hello, I just want to send some love to the person who can fix this bug. <3

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

Try the very latest kernel, which received a few important USB-audio fixes.

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

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

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.

Created attachment 300806 [details]
stream0 5.10

Created attachment 300807 [details]
stream0 5.18

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

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 */

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 ?

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

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.

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

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.

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

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

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

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

Could you attach the stream0 contents from procfs (/proc/asound/card*) when the IMPLICIT_FB_SKIP_DEV patch is applied ?

Created attachment 300820 [details]
stream0 with patched 5.18

Could you try to turn off lowlatency using the kernel module parameter? (modinfo snd-usb-audio | grep lowlatency)

Kernel 5.18-rc4 with the IMPLICIT_FB_SKIP_DEV patch and lowlatency parameter to no, there is sound but the stutters are present.

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.

Created attachment 300841 [details]
usbcapture 5.10

Created attachment 300842 [details]
usbcapture 5.18 without patch

Created attachment 300843 [details]
usbcapture 5.18 patched

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.

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.

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

Created attachment 300847 [details]
usbcapture 5.18 without patch with arecord

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

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.

Do test only with IMPLICIT_FB_SKIP_DEV patch applied, too.

Created attachment 300867 [details]
usbcapture 5.18-rc5 patched and reverted

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.

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.

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.

Created attachment 300882 [details]
Revert altno interface setttings in stream.c

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.

Created attachment 300890 [details]
usbcapture 5.18-rc5 patched and reverted again

(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

Created attachment 300906 [details]
Modify altno settings (#2)

Please, the test patch from comment#65. Same steps as in comment#62 (IMPLICIT_FB_SKIP_DEV patch + this new patch).

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

Created attachment 300917 [details]
Modify altno settings (#3)

Fixed patch in comment#65.

Created attachment 300919 [details]
usbcapture 5.18-rc6 implicit and ep2 patches

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.

A possibly relevant problem is the handling of the shared clock source.
Could you try the patch below?

Created attachment 300939 [details]
Test fix for clock refecounting

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.

Created attachment 300940 [details]
module crash with 5.18-rc6 and 0001-ALSA-usb-audio-Refcount-multiple-accesses-on-the-sin patch

My bad, a missing hunk in the patch.  Now the revised patch attached.

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

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 ?

OK, just to be sure, yet more revised patch (v3) is below.

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

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

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

Could you test / provide usbcapture for the patch in comment#80 ? Thank you.

Created attachment 300946 [details]
usbcapture 5.18-rc6 implicit and ep3 patches

(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

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 ?

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.

Created attachment 300949 [details]
Initialize sync_ep (implicit feedback stream) as first

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?

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.

Tested that patch alone on 5.18rc6, there's no audio output on speaker-test.

Created attachment 300951 [details]
Initialize sync_ep (implicit feedback stream) as first + delay

Another path to try with the latest kernel. Please, provide the usbcapture output, if things do not work.

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.

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

Below is another test fix.  Can anyone check it?

Created attachment 300993 [details]
Another test fix

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

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 ?

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.

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

Hi back. I’ve just tested this patch, alone, on a 5.18-rc7 kernel. There is no sound unless I launch arecord before.

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

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 ?

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?

And, you've already tried QUIRK_FLAG_PLAYBACK_FIRST quirk, right?

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.

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?

Created attachment 301017 [details]
Patch fixing the GoXLR Output

I've double checked, and it's not needed. Adjusted patch attached.

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

Created attachment 301018 [details]
Call snd_usb_endpoint_configure() after sync_pending_stops() for sync_endpoint

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?

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.

Created attachment 301021 [details]
Git patch with fix

Git patch attached.

Thak you so much <3

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 !