[PATCH] ALSA: usb-audio: Apply sample rate quirk to Logitech Connect
Logitech ConferenceCam Connect is a compound USB device with UVC and UAC. Not 100% reproducible but sometimes it keeps responding STALL to every control transfer once it receives get_freq request.
This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 Signed-off-by: Ikjoon Jang ikjn@chromium.org
---
sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index d3001fb18141..176437a441e6 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1521,6 +1521,7 @@ bool snd_usb_get_sample_rate_quirk(struct snd_usb_audio *chip) case USB_ID(0x21b4, 0x0081): /* AudioQuest DragonFly */ case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */ case USB_ID(0x413c, 0xa506): /* Dell AE515 sound bar */ + case USB_ID(0x046d, 0x084c): /* Logitech ConferenceCam Connect */ return true; }
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote:
Logitech ConferenceCam Connect is a compound USB device with UVC and UAC. Not 100% reproducible but sometimes it keeps responding STALL to every control transfer once it receives get_freq request.
This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 Signed-off-by: Ikjoon Jang ikjn@chromium.org
Most Logitech USB headset I got needs a delay in snd_usb_ctl_msg_quirk() Have you tried to add say 20 ms delay in there?
Jocke
On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund < Joakim.Tjernlund@infinera.com> wrote:
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote:
Logitech ConferenceCam Connect is a compound USB device with UVC and UAC. Not 100% reproducible but sometimes it keeps responding STALL to every control transfer once it receives get_freq request.
This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 Signed-off-by: Ikjoon Jang ikjn@chromium.org
Most Logitech USB headset I got needs a delay in snd_usb_ctl_msg_quirk() Have you tried to add say 20 ms delay in there?
I didn't try that. But it sounds reasonable to me.
let me try that quirk here. If that is the case, HID might need that delay also. Logitech Group webcam had a similar problem on control xfer of get_report from an another interface for HID.
And 20ms can be too long if it's applied to every control transfer. I will test the device with shorter delay if you didn't try it before.
Any additional advice is welcome.
Thanks!
Jocke
Dear list administrator,
please remove dmitry@d-systems.ee from this list.
Kind regards, Dmitry Panchenko
d-Systems OÜ Ⓐ Lai 6, Tartu 51005, Estonia Ⓦ www.d-systems.ee http://www.d-systems.ee
On 24.03.21 14:03, Ikjoon Jang wrote:
On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund <Joakim.Tjernlund@infinera.com mailto:Joakim.Tjernlund@infinera.com> wrote:
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote: > Logitech ConferenceCam Connect is a compound USB device with UVC and > UAC. Not 100% reproducible but sometimes it keeps responding STALL to > every control transfer once it receives get_freq request. > > This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 > Signed-off-by: Ikjoon Jang <ikjn@chromium.org <mailto:ikjn@chromium.org>> Most Logitech USB headset I got needs a delay in snd_usb_ctl_msg_quirk() Have you tried to add say 20 ms delay in there?I didn't try that. But it sounds reasonable to me.
let me try that quirk here. If that is the case, HID might need that delay also. Logitech Group webcam had a similar problem on control xfer of get_report from an another interface for HID.
And 20ms can be too long if it's applied to every control transfer. I will test the device with shorter delay if you didn't try it before.
Any additional advice is welcome.
Thanks!
Jocke
On Wed, 24 Mar 2021 13:03:14 +0100, Ikjoon Jang wrote:
On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund Joakim.Tjernlund@infinera.com wrote:
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote: > Logitech ConferenceCam Connect is a compound USB device with UVC and > UAC. Not 100% reproducible but sometimes it keeps responding STALL to > every control transfer once it receives get_freq request. > > This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 > Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Most Logitech USB headset I got needs a delay in snd_usb_ctl_msg_quirk() Have you tried to add say 20 ms delay in there?I didn't try that. But it sounds reasonable to me.
let me try that quirk here. If that is the case, HID might need that delay also. Logitech Group webcam had a similar problem on control xfer of get_report from an another interface for HID.
The Logitech devices with 046d:* should be covered generally in snd_usb_ctl_msg_quirk(), so I guess it's a different problem. But please check it first.
And 20ms can be too long if it's applied to every control transfer. I will test the device with shorter delay if you didn't try it before.
Actually the delay applied to Logitech devices is from 1 to 2ms, not 20ms. The 20ms delay is applied for some other devices. But if extending the delay fixes the problem, we need to reconsider the delay length.
Takashi
On Wed, 2021-03-24 at 13:49 +0100, Takashi Iwai wrote:
On Wed, 24 Mar 2021 13:03:14 +0100, Ikjoon Jang wrote:
On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund Joakim.Tjernlund@infinera.com wrote:
The Logitech devices with 046d:* should be covered generally in snd_usb_ctl_msg_quirk(), so I guess it's a different problem. But please check it first.
And 20ms can be too long if it's applied to every control transfer. I will test the device with shorter delay if you didn't try it before.
Actually the delay applied to Logitech devices is from 1 to 2ms, not 20ms. The 20ms delay is applied for some other devices. But if extending the delay fixes the problem, we need to reconsider the delay length.
There are a lot of devices USB Audio devices that need that 1-2 ms delay. Have you considered to make this delay generic(for all Audio USB devices) ? Seems like Windows has something similar as these devices just work there.
Jocke
On Wed, Mar 24, 2021 at 8:49 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 24 Mar 2021 13:03:14 +0100, Ikjoon Jang wrote:
On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund Joakim.Tjernlund@infinera.com wrote:
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote: > Logitech ConferenceCam Connect is a compound USB device with UVC and > UAC. Not 100% reproducible but sometimes it keeps responding STALL to > every control transfer once it receives get_freq request. > > This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 > Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Most Logitech USB headset I got needs a delay in snd_usb_ctl_msg_quirk() Have you tried to add say 20 ms delay in there?I didn't try that. But it sounds reasonable to me.
let me try that quirk here. If that is the case, HID might need that delay also. Logitech Group webcam had a similar problem on control xfer of get_report from an another interface for HID.
The Logitech devices with 046d:* should be covered generally in snd_usb_ctl_msg_quirk(), so I guess it's a different problem. But please check it first.
And 20ms can be too long if it's applied to every control transfer. I will test the device with shorter delay if you didn't try it before.
Actually the delay applied to Logitech devices is from 1 to 2ms, not 20ms. The 20ms delay is applied for some other devices. But if extending the delay fixes the problem, we need to reconsider the delay length.
I tested this Logitech device with various delays 2..20ms in snd_usb_ctl_msg_quirk() but it didn't help.
Disregarding the delay between control transfers, This device is always stuck at get_cur, responding STALL to all control transfers.
[ 24.045618] usb 1-1.2.1.1: 1:1: cannot get freq at ep 0x82 [ 24.167475] usb 1-1.2.1.1: 2:0: cannot get min/max values for control 2 (id 2) [ 24.287393] usb 1-1.2.1.1: 6:0: cannot get min/max values for control 2 (id 6) [ 24.289854] usbcore: registered new interface driver snd-usb-audio [ 24.877073] usb 1-1.2.1.1: 2:1: usb_set_interface failed (-32)
And I've also found that in some other platforms (with the same kernel), this device fails at get_freq - timeout with NYETs or NAKs (instead of STALL), and succeeded in following set_interface even without any delays I've tried but couldn't find any differences between the two. ;-(
So until now, I think this approach of skipping get_rate is the only one possible workaround for Logitech Connect.
Takashi
On Mon, 29 Mar 2021 08:23:52 +0200, Ikjoon Jang wrote:
On Wed, Mar 24, 2021 at 8:49 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 24 Mar 2021 13:03:14 +0100, Ikjoon Jang wrote:
On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund Joakim.Tjernlund@infinera.com wrote:
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote: > Logitech ConferenceCam Connect is a compound USB device with UVC and > UAC. Not 100% reproducible but sometimes it keeps responding STALL to > every control transfer once it receives get_freq request. > > This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 > Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Most Logitech USB headset I got needs a delay in snd_usb_ctl_msg_quirk() Have you tried to add say 20 ms delay in there?I didn't try that. But it sounds reasonable to me.
let me try that quirk here. If that is the case, HID might need that delay also. Logitech Group webcam had a similar problem on control xfer of get_report from an another interface for HID.
The Logitech devices with 046d:* should be covered generally in snd_usb_ctl_msg_quirk(), so I guess it's a different problem. But please check it first.
And 20ms can be too long if it's applied to every control transfer. I will test the device with shorter delay if you didn't try it before.
Actually the delay applied to Logitech devices is from 1 to 2ms, not 20ms. The 20ms delay is applied for some other devices. But if extending the delay fixes the problem, we need to reconsider the delay length.
I tested this Logitech device with various delays 2..20ms in snd_usb_ctl_msg_quirk() but it didn't help.
Disregarding the delay between control transfers, This device is always stuck at get_cur, responding STALL to all control transfers.
[ 24.045618] usb 1-1.2.1.1: 1:1: cannot get freq at ep 0x82 [ 24.167475] usb 1-1.2.1.1: 2:0: cannot get min/max values for control 2 (id 2) [ 24.287393] usb 1-1.2.1.1: 6:0: cannot get min/max values for control 2 (id 6) [ 24.289854] usbcore: registered new interface driver snd-usb-audio [ 24.877073] usb 1-1.2.1.1: 2:1: usb_set_interface failed (-32)
And I've also found that in some other platforms (with the same kernel), this device fails at get_freq - timeout with NYETs or NAKs (instead of STALL), and succeeded in following set_interface even without any delays I've tried but couldn't find any differences between the two. ;-(
So until now, I think this approach of skipping get_rate is the only one possible workaround for Logitech Connect.
OK, that makes sense, then. I applied your patch now.
Thanks!
Takashi
participants (4)
-
Dmitry Panchenko | d-Systems -
Ikjoon Jang -
Joakim Tjernlund -
Takashi Iwai