Dne 07. 05. 21 v 10:37 Pavel Hofman napsal(a):
Hi,
The X-Fi USB HD device (and likely the similar 5.1 model too) can run at USB1.1 (with limited samplerates) and USB2 modes (with full specs). In linux the device stays at USB1.1. If connected to Windows with stock windows USB driver the same happens. However, when the Creative proprietary driver is installed, the device switches to USB2 and supports all features. When rebooting to linux without re-plugging, the USB2 mode stays and the device offers its USB2 configurations to snd-usb-audio.
We captured USB packets in linux and Win7 with wireshark - both dumps are included. The windows dump shows that in windows as well as in linux the device starts as device 3.5.0 at USB1.1:
DEVICE DESCRIPTOR bLength: 18 bDescriptorType: 0x01 (DEVICE) bcdUSB: 0x0110 bDeviceClass: Device (0x00) bDeviceSubClass: 0 bDeviceProtocol: 0 (Use class code info from Interface Descriptors) bMaxPacketSize0: 64 idVendor: Creative Technology, Ltd (0x041e) idProduct: Unknown (0x30d7) bcdDevice: 0x0100 iManufacturer: 1 iProduct: 2 iSerialNumber: 3 bNumConfigurations: 1
After USB1.1 enumeration, the windows host controlled by the vendor driver sends a request USR_FUNCTION_ABORT_PIPE to EP IN 6:
The EP IN 6 descriptor (from USB1.1 configuration):
ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x86 IN Endpoint:6 1... .... = Direction: IN Endpoint .... 0110 = Endpoint Number: 0x6 bmAttributes: 0x03 .... ..11 = Transfertype: Interrupt-Transfer (0x3) wMaxPacketSize: 64 ...0 0... .... .... = Transactions per microframe: 1 (0) .... ..00 0100 0000 = Maximum Packet Size: 64 bInterval: 1
The request sent by the host is: USB URB [Source: host] [Destination: 3.5.6] USBPcap pseudoheader length: 27 IRP ID: 0xfffffa80073ee120 IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) URB Function: URB_FUNCTION_ABORT_PIPE (0x0002) IRP information: 0x00, Direction: FDO -> PDO URB bus id: 3 Device address: 5 Endpoint: 0x86, Direction: IN URB transfer type: USB IRP Info (0xfe) Packet Data Length: 0
The device responds with a proprietary response, with a different source 3.5.127: USB URB [Source: 3.5.127] [Destination: host] USBPcap pseudoheader length: 27 IRP ID: 0xfffffa80073ee120 IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) URB Function: URB_FUNCTION_ABORT_PIPE (0x0002) IRP information: 0x01, Direction: PDO -> FDO 0000 000. = Reserved: 0x00 .... ...1 = Direction: PDO -> FDO (0x1) URB bus id: 3 Device address: 5 Endpoint: 0xff, Direction: IN 1... .... = Direction: IN (1) .... 1111 = Endpoint number: 15 URB transfer type: Unknown (0xff) [Expert Info (Error/Malformed): USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)] [USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)] [Severity level: Error] [Group: Malformed] Packet Data Length: 0
Immediately after that the device re-connects as 3.6.0 and reports its USB2.0 description:
DEVICE DESCRIPTOR bLength: 18 bDescriptorType: 0x01 (DEVICE) bcdUSB: 0x0200 bDeviceClass: Device (0x00) bDeviceSubClass: 0 bDeviceProtocol: 0 (Use class code info from Interface Descriptors) bMaxPacketSize0: 64 idVendor: Creative Technology, Ltd (0x041e) idProduct: Unknown (0x30d7) bcdDevice: 0x0100 iManufacturer: 1 iProduct: 2 iSerialNumber: 3 bNumConfigurations: 1
This is a regular USB-audio device which works OK in snd-usb-audio, as tested after rebooting from windows to linux.
Please is there any similar case handled by the existing alsa usb driver which we could try to modify and test? My USB skills are not up to writing the required code myself from scratch, unfortunately.
The switch can be probably implemented in the user space (libusb + udev rules). There is something similar for modems (usb_modeswitch).
Jaroslav