Ignored USB-audio implicit feedback in kernel 5.8rc3
Hi,
Audio analyzer RTX6001 (XMOS-based) is using implicit feedback, yet the feedback is not used by the latest kernel 5.8 rc3 (i.e. already with the latest implicit-feedback patches).
Two analyzers on two different PCs are getting clicks in duplex-mode loobpack, one every 10 secs, the other one every 50 secs.
While running aplay/arecord loopback I captured USB packets with tcpdump/tshark. The dump contained 931484 IN packets with 48bytes payload, and 684 IN packets with 40 bytes payload. Packet interval 125us (bInterval = 1), 32bits, 2ch => precise samplerate 47,994.1298Hz. Clearly the incoming stream works OK. Yet stream0 file states for Capture:
Momentary freq = 48000 Hz (0x6.0000)
But ONLY 48bytes packets were sent by the host in OUT packets, i.e. exactly 48kHz output rate. 6 frames OUT/IN difference per second, the incoming FIFO in the device overflows after several seconds.
Please may I ask for help with making the driver respect the implicit feedback stream?
Best regards,
Pavel.
5.8.0-050800-generic #202006282330 SMP Sun Jun 28 23:35:41 UTC 2020 x86_64 GNU/Linux
cat /proc/asound/card4/stream0 RTX A/S RTX6001 USB Audio 2.0 at usb-0000:00:13.2-4, high speed : USB Audio
Playback: Status: Running Interface = 1 Altset = 1 Packet Size = 72 Momentary freq = 48000 Hz (0x6.0000) Interface 1 Altset 1 Format: S32_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 32 Channel map: FL FR Interface 1 Altset 2 Format: S32_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 24 Channel map: FL FR Interface 1 Altset 3 Format: S16_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 16 Channel map: FL FR
Capture: Status: Stop Interface 2 Altset 1 Format: S32_LE Channels: 2 Endpoint: 1 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 32 Channel map: FL FR Interface 2 Altset 2 Format: S32_LE Channels: 2 Endpoint: 1 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 24 Channel map: FL FR Interface 2 Altset 3 Format: S16_LE Channels: 2 Endpoint: 1 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 16 Channel map: FL FR
lsusb: Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer Bus 002 Device 003: ID 0d9a:00df RTX AS RTX6001 USB Audio 2.0 <---- Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 008: ID 2047:0301 Texas Instruments Arduino Micro Bus 004 Device 007: ID 18f8:0f97 [Maxxter] Elo TouchSystems 2216 AccuTouch® USB Touchmonitor Interface Bus 004 Device 006: ID 413c:2001 Dell Computer Corp. Keyboard HID Support Bus 004 Device 005: ID 413c:1001 Dell Computer Corp. Keyboard Hub Bus 004 Device 004: ID 0bd9:0001 Liberty Instruments, Inc. Liberty Praxis AudPod 1.1 Bus 004 Device 003: ID 2341:8037 Arduino SA Arduino Micro Bus 004 Device 002: ID 04e7:0050 Elo TouchSystems 2216 AccuTouch® Touchmonitor Interface Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 009 Device 002: ID 18a5:0422 Verbatim, Ltd Portable SSD Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
lsusb -v see the attachment
Dne 29. 06. 20 v 13:28 Pavel Hofman napsal(a):
Audio analyzer RTX6001 (XMOS-based) is using implicit feedback, yet the feedback is not used by the latest kernel 5.8 rc3 (i.e. already with the latest implicit-feedback patches).
Two analyzers on two different PCs are getting clicks in duplex-mode loobpack, one every 10 secs, the other one every 50 secs.
I am sorry, correct stream0 for duplex operation (kernel 5.4, the same behaviour as in 5.8-rc3):
RTX A/S RTX6001 USB Audio 2.0 at usb-0000:00:13.2-4, high speed : USB Audio
Playback: Status: Running Interface = 1 Altset = 1 Packet Size = 72 Momentary freq = 48000 Hz (0x6.0000) Interface 1 Altset 1 Format: S32_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 32 Interface 1 Altset 2 Format: S32_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 24 Interface 1 Altset 3 Format: S16_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 16
Capture: Status: Running Interface = 2 Altset = 1 Packet Size = 72 Momentary freq = 48000 Hz (0x6.0000) Interface 2 Altset 1 Format: S32_LE Channels: 2 Endpoint: 1 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 32 Interface 2 Altset 2 Format: S32_LE Channels: 2 Endpoint: 1 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 24 Interface 2 Altset 3 Format: S16_LE Channels: 2 Endpoint: 1 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Bits: 16
Thanks a lot.
Pavel.
Dne 29. 06. 20 v 17:08 Pavel Hofman napsal(a):
Dne 29. 06. 20 v 13:28 Pavel Hofman napsal(a):
Audio analyzer RTX6001 (XMOS-based) is using implicit feedback, yet the feedback is not used by the latest kernel 5.8 rc3 (i.e. already with the latest implicit-feedback patches).
Two analyzers on two different PCs are getting clicks in duplex-mode loobpack, one every 10 secs, the other one every 50 secs.
I am very sure the problem is identical to that for MOTU M2/4, Solid State Logic SSL2+, Fractal Audio Axe-Fx III etc. https://github.com/torvalds/linux/commit/e7585db1b0b5b4e4eb1967bb1472df308f7... . I will try the simple quirk, IMO it will work OK. BTW if I understand correctly all these devices use the XMOS.
However, I would like to ask, why a quirk for these devices is required. The comment explanation in this interesting patch https://lore.kernel.org/patchwork/patch/1174179/ talks about the same EP numbers, but in the different direction. 0x01 EP OUT + 0x81 EP IN implicit feedback data. All the devices mentioned above have this numbering, just the EP IN is in a different interface than the EP OUT. But please are there actually any duplex implicit feedback devices having EP OUT and implicit-feedback EP IN in the same interface? The explicit feedback EP IN is clear, they are in the same interface. E-MU 0404 USB has EP OUT + EP IN explicit feedback in interface 1, together, EP IN implicit feedback data in interface 2. My other soundcards, adaptive OUT and async IN again each in a different interface (though there is no feedback to solve).
Please is the requirement that EP OUT + EP IN implicit feedback data must be in the same interface really necessary? If such a requirement was dropped, IMO many devices could be removed from the existing set_sync_ep_implicit_fb_quirk and many devices would work out of the box, as they require no other quirk (unlike the MOTUs, but that's a different issue).
Thank you very much for comments. Very likely I am missing something important, I just do not see what :-)
Best regards,
Pavel.
Dne 02. 07. 20 v 13:28 Pavel Hofman napsal(a):
Please is the requirement that EP OUT + EP IN implicit feedback data must be in the same interface really necessary? If such a requirement was dropped, IMO many devices could be removed from the existing set_sync_ep_implicit_fb_quirk and many devices would work out of the box,
I am still thinking about the single-interface requirement. If both endpoints were to be part of a single interface, could they use different altsettings for different sample lengths for capture and playback? E.g. to save USB bandwidth when the capture is used only for implicit feedback - capturing at 16bits, playback at 32bits.
In the quirked XMOS devices the common clock for both directions is defined by the clock feature, the altsettings for each direction (in separate interfaces) are used for setting sample length.
Thank you very much for any insight into the issue. IMO not having to add quirks before a device starts working would be advantageous for all involved.
Best regards,
Pavel.
On Fri, 03 Jul 2020 12:17:14 +0200, Pavel Hofman wrote:
Dne 02. 07. 20 v 13:28 Pavel Hofman napsal(a):
Please is the requirement that EP OUT + EP IN implicit feedback data must be in the same interface really necessary? If such a requirement was dropped, IMO many devices could be removed from the existing set_sync_ep_implicit_fb_quirk and many devices would work out of the box,
I am still thinking about the single-interface requirement. If both endpoints were to be part of a single interface, could they use different altsettings for different sample lengths for capture and playback? E.g. to save USB bandwidth when the capture is used only for implicit feedback - capturing at 16bits, playback at 32bits.
In the quirked XMOS devices the common clock for both directions is defined by the clock feature, the altsettings for each direction (in separate interfaces) are used for setting sample length.
Thank you very much for any insight into the issue. IMO not having to add quirks before a device starts working would be advantageous for all involved.
Could you check for-linus branch of my sound git tree? Just to be sure whether you're hitting the issue that has been already addressed.
thanks,
Takashi
Hi Takashi,
Dne 07. 07. 20 v 11:40 Takashi Iwai napsal(a):
On Fri, 03 Jul 2020 12:17:14 +0200, Pavel Hofman wrote:
Dne 02. 07. 20 v 13:28 Pavel Hofman napsal(a):
Please is the requirement that EP OUT + EP IN implicit feedback data must be in the same interface really necessary? If such a requirement was dropped, IMO many devices could be removed from the existing set_sync_ep_implicit_fb_quirk and many devices would work out of the box,
I am still thinking about the single-interface requirement. If both endpoints were to be part of a single interface, could they use different altsettings for different sample lengths for capture and playback? E.g. to save USB bandwidth when the capture is used only for implicit feedback - capturing at 16bits, playback at 32bits.
In the quirked XMOS devices the common clock for both directions is defined by the clock feature, the altsettings for each direction (in separate interfaces) are used for setting sample length.
Could you check for-linus branch of my sound git tree? Just to be sure whether you're hitting the issue that has been already addressed.
I developed the RTX6001 patch on 5.8-rc3 kernel, and commits since that tag in https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-l... do not seem to address the issue.
I think the generic code searching for the implicit-feedback endpoint works only on the current interface (alts) https://github.com/tiwai/sound/blob/master/sound/usb/pcm.c#L491
I do not know if searching for IN endpoints with the same number and USB_ENDPOINT_USAGE_IMPLICIT_FB mask in other interfaces is correct. But it seems to me it would yield correct results for a number of existing quirks in set_sync_ep_implicit_fb_quirk (typically those setting ep=0x81).
Thanks a lot,
Pavel.
On Tue, 07 Jul 2020 12:03:25 +0200, Pavel Hofman wrote:
Hi Takashi,
Dne 07. 07. 20 v 11:40 Takashi Iwai napsal(a):
On Fri, 03 Jul 2020 12:17:14 +0200, Pavel Hofman wrote:
Dne 02. 07. 20 v 13:28 Pavel Hofman napsal(a):
Please is the requirement that EP OUT + EP IN implicit feedback data must be in the same interface really necessary? If such a requirement was dropped, IMO many devices could be removed from the existing set_sync_ep_implicit_fb_quirk and many devices would work out of the box,
I am still thinking about the single-interface requirement. If both endpoints were to be part of a single interface, could they use different altsettings for different sample lengths for capture and playback? E.g. to save USB bandwidth when the capture is used only for implicit feedback - capturing at 16bits, playback at 32bits.
In the quirked XMOS devices the common clock for both directions is defined by the clock feature, the altsettings for each direction (in separate interfaces) are used for setting sample length.
Could you check for-linus branch of my sound git tree? Just to be sure whether you're hitting the issue that has been already addressed.
I developed the RTX6001 patch on 5.8-rc3 kernel, and commits since that tag in https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-l... do not seem to address the issue.
I think the generic code searching for the implicit-feedback endpoint works only on the current interface (alts) https://github.com/tiwai/sound/blob/master/sound/usb/pcm.c#L491
I do not know if searching for IN endpoints with the same number and USB_ENDPOINT_USAGE_IMPLICIT_FB mask in other interfaces is correct. But it seems to me it would yield correct results for a number of existing quirks in set_sync_ep_implicit_fb_quirk (typically those setting ep=0x81).
Yeah I found your patch later. Now it's in for-linus branch, too.
Takashi
В Чт, 02/07/2020 в 13:28 +0200, Pavel Hofman пишет:
Dne 29. 06. 20 v 17:08 Pavel Hofman napsal(a):
Dne 29. 06. 20 v 13:28 Pavel Hofman napsal(a):
Audio analyzer RTX6001 (XMOS-based) is using implicit feedback, yet the feedback is not used by the latest kernel 5.8 rc3 (i.e. already with the latest implicit-feedback patches).
Two analyzers on two different PCs are getting clicks in duplex- mode loobpack, one every 10 secs, the other one every 50 secs.
I am very sure the problem is identical to that for MOTU M2/4, Solid State Logic SSL2+, Fractal Audio Axe-Fx III etc. https://github.com/torvalds/linux/commit/e7585db1b0b5b4e4eb1967bb1472df308f7... . I will try the simple quirk, IMO it will work OK. BTW if I understand correctly all these devices use the XMOS.
However, I would like to ask, why a quirk for these devices is required. The comment explanation in this interesting patch https://lore.kernel.org/patchwork/patch/1174179/ talks about the same EP numbers, but in the different direction. 0x01 EP OUT + 0x81 EP IN implicit feedback data. All the devices mentioned above have this numbering, just the EP IN is in a different interface than the EP OUT. But please are there actually any duplex implicit feedback devices having EP OUT and implicit-feedback EP IN in the same interface? The explicit feedback EP IN is clear, they are in the same interface. E- MU 0404 USB has EP OUT + EP IN explicit feedback in interface 1, together, EP IN implicit feedback data in interface 2. My other soundcards, adaptive OUT and async IN again each in a different interface (though there is no feedback to solve).
Please is the requirement that EP OUT + EP IN implicit feedback data must be in the same interface really necessary? If such a requirement was dropped, IMO many devices could be removed from the existing set_sync_ep_implicit_fb_quirk and many devices would work out of the box, as they require no other quirk (unlike the MOTUs, but that's a different issue).
USB Audio Class specs are pretty clear about it: only one isochronous endpoint is allowed per interface. And it can be accompanied by the *explicit* feedback endpoint.
I have patches that implement autodetection of implicit feedback, but I need to clean them up and be careful not to break Scarlett 18i8/18i20 3rd Gen (these devices have 3 altsettings per interface and probably require some additional sample rates filtering, so that each sample rate uniquely match one single altsetting).
Dne 07. 07. 20 v 12:34 Alexander Tsoy napsal(a):
В Чт, 02/07/2020 в 13:28 +0200, Pavel Hofman пишет:
USB Audio Class specs are pretty clear about it: only one isochronous endpoint is allowed per interface. And it can be accompanied by the *explicit* feedback endpoint.
I have patches that implement autodetection of implicit feedback, but I need to clean them up and be careful not to break Scarlett 18i8/18i20 3rd Gen (these devices have 3 altsettings per interface and probably require some additional sample rates filtering, so that each sample rate uniquely match one single altsetting).
Alexander, thanks for the clarification. If I understand correctly the existing single-interface condition is incorrect and no implicit-feedback device can work without a quirk now.
Thanks for your WIP patches, very much appreciated.
Best regards,
Pavel.
participants (3)
-
Alexander Tsoy -
Pavel Hofman -
Takashi Iwai