[alsa-devel] Boss GT-001
I recently got access to a Boss GT-001. This is a small USB audio Interface for guitar with onboard FX which doesn't work with ALSA under Linux Mint 17 (running kernel 3.16.0-38-generic).
I've not tried it with the latest ALSA development branch, but scanning the recent ALSA Dev archives, I can't see anything which might fix this.
# lsusb ... Bus 001 Device 011: ID 0582:0187 Roland Corp
(detailed lsusb output is towards the bottom of this email)
The unit is moderately quirky compared to most audio devices. This unit includes on-board Boss guitar amp emulations and effects and the USB connection allows you to simultaneously record both the "wet" (with effects) and "dry" (without effects) signal. Thus the USB carries two separate stereo pairs to the computer.
It also allows "re-amping" which allows you to apply effects to the output signal. The way this seems to do this is by having two separate stereo pair outputs from the computer one of which is processed via the onboard effects, and one of which is not.
This is all just background, but the upshot of this is that the unit is a 2x stereo pair in, and 2x stereo pair out. However, this not only does not show up properly under Linux, but it will not play or record anything.
ALSA sees it thusly: # aplay -l ... card 4: GT001 [GT-001], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0
PLaying a CD-format file: # aplay hw:4 test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: set_params:1233: Sample format not available Available formats: - S32_LE
# aplay hw:4 test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
No audio is output
For input: # arecord -l card 4: GT001 [GT-001], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0
The unit also supports MIDI which is used for both control of the unit itself via a PC editing application (editing settings, changing patches, etc.) and for simple DAW control. There are three USB MIDI ports for this which, on Windows, are labelled "GT-001", "GT-001 DAW CTRL" and "GT-001 CTRL"
On Linux these show up as follows: # amidi -l IO hw:4,0,0 GT-001 MIDI 1 IO hw:4,0,1 GT-001 MIDI 2 IO hw:4,0,2 GT-001 MIDI 3
Any advice and pointers to get this working would be appreciated.
Dmesg output: [17530.759008] usb 1-1: new high-speed USB device number 12 using ehci-pci [17530.893299] usb 1-1: New USB device found, idVendor=0582, idProduct=0187 [17530.893303] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [17530.893305] usb 1-1: Product: GT-001 [17530.893307] usb 1-1: Manufacturer: BOSS [17530.894412] snd-usb-audio: probe of 1-1:1.0 failed with error -5 [17530.927591] usb 1-1: Unable to change format on ep #8e: already in use [17530.927614] usb 1-1: Unable to change format on ep #8e: already in use [17530.927764] usb 1-1: Unable to change format on ep #8e: already in use [17530.927945] usb 1-1: Unable to change format on ep #8e: already in use [17530.928161] usb 1-1: Unable to change format on ep #8e: already in use [17530.928600] usb 1-1: Unable to change format on ep #8e: already in use [17530.928620] usb 1-1: Unable to change format on ep #8e: already in use [17530.928693] usb 1-1: Unable to change format on ep #8e: already in use [17530.928832] usb 1-1: Unable to change format on ep #8e: already in use [17530.928958] usb 1-1: Unable to change format on ep #8e: already in use [17530.929350] usb 1-1: Unable to change format on ep #8e: already in use [17530.929377] usb 1-1: Unable to change format on ep #8e: already in use [17530.929500] usb 1-1: Unable to change format on ep #8e: already in use [17530.929743] usb 1-1: Unable to change format on ep #8e: already in use [17530.929988] usb 1-1: Unable to change format on ep #8e: already in use [17530.930577] usb 1-1: Unable to change format on ep #8e: already in use [17530.930617] usb 1-1: Unable to change format on ep #8e: already in use [17530.930808] usb 1-1: Unable to change format on ep #8e: already in use [17530.931064] usb 1-1: Unable to change format on ep #8e: already in use [17530.931213] usb 1-1: Unable to change format on ep #8e: already in use [17531.330778] usb 1-1: Unable to change format on ep #8e: already in use [17531.334500] usb 1-1: Unable to change format on ep #8e: already in use
lsusb output: lsusb -vv -d 0582:0187
Bus 001 Device 011: ID 0582:0187 Roland Corp. Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x0187 bcdDevice 0.00 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 176 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 04 04 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0070 1x 112 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 04 04 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0070 1x 112 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 03 03 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1
Cheers,
Keith
On Friday 18 Sep 2015 21:03:15 maillist@superlative.org wrote:
I recently got access to a Boss GT-001. This is a small USB audio Interface for guitar with onboard FX which doesn't work with ALSA under Linux Mint 17 (running kernel 3.16.0-38-generic).
<SNIP>
Following up on this, here's the output from aadebug:
ALSA Audio Debug v0.2.0 - Mon Sep 21 11:17:55 BST 2015 http://alsa.opensrc.org/aadebug http://www.gnu.org/licenses/agpl-3.0.txt
Kernel ---------------------------------------------------- Linux KAMDesktop 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Advanced Linux Sound Architecture Driver Version k3.16.0-38-generic.
Loaded Modules -------------------------------------------- snd_hrtimer 12744 0 snd_seq_dummy 12762 0 snd_usb_audio 161870 8 snd_usbmidi_lib 29828 1 snd_usb_audio snd_hwdep 17698 1 snd_usb_audio snd_aloop 23396 0 snd_pcm 104112 2 snd_usb_audio,snd_aloop snd_seq_midi 13564 0 snd_seq_midi_event 14899 1 snd_seq_midi snd_rawmidi 30876 2 snd_usbmidi_lib,snd_seq_midi snd_seq 63074 3 snd_seq_midi_event,snd_seq_dummy,snd_seq_midi snd_seq_device 14497 4 snd_seq,snd_rawmidi,snd_seq_dummy,snd_seq_midi snd_timer 29562 3 snd_hrtimer,snd_pcm,snd_seq snd 79468 25 snd_usb_audio,snd_aloop,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_seq_device
Proc Asound ----------------------------------------------- 0 [C920 ]: USB-Audio - HD Pro Webcam C920 HD Pro Webcam C920 at usb-0000:00:1d.7-4, high speed 1 [Loopback ]: Loopback - Loopback Loopback 1 2 [VS20 ]: USB-Audio - VS-20 Cakewalk VS-20 at usb-0000:00:1a.1-2, full speed 3 [CODEC ]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-0000:00:1a.7-6.4, full speed 4 [GT001 ]: USB-Audio - GT-001 BOSS GT-001 at usb-0000:00:1a.7-1, high speed 1: : sequencer 2: [ 1] : control 3: [ 1- 0]: digital audio playback 4: [ 1- 0]: digital audio capture 5: [ 1- 1]: digital audio playback 6: [ 1- 1]: digital audio capture 7: [ 2] : control 8: [ 2- 0]: digital audio playback 9: [ 2- 0]: digital audio capture 10: [ 2- 0]: raw midi 11: [ 0] : control 12: [ 0- 0]: digital audio capture 13: [ 3] : control 14: [ 3- 0]: digital audio playback 15: [ 3- 0]: digital audio capture 16: [ 4] : control 17: [ 4- 0]: digital audio playback 18: [ 4- 0]: digital audio capture 19: [ 4- 0]: raw midi 33: : timer 00-00: USB Audio : USB Audio : capture 1 01-00: Loopback PCM : Loopback PCM : playback 8 : capture 8 01-01: Loopback PCM : Loopback PCM : playback 8 : capture 8 02-00: USB Audio : USB Audio : playback 1 : capture 1 03-00: USB Audio : USB Audio : playback 1 : capture 1 04-00: USB Audio : USB Audio : playback 1 : capture 1 Client info cur clients : 4 peak clients : 5 max clients : 192
Client 0 : "System" [Kernel] Port 0 : "Timer" (Rwe-) Port 1 : "Announce" (R-e-) Client 14 : "Midi Through" [Kernel] Port 0 : "Midi Through Port-0" (RWe-) Port 1 : "Midi Through Port-1" (RWe-) Port 2 : "Midi Through Port-2" (RWe-) Port 3 : "Midi Through Port-3" (RWe-) Client 24 : "VS-20" [Kernel] Port 0 : "VS-20 MIDI 1" (RWeX) Port 1 : "VS-20 MIDI 2" (RWeX) Client 32 : "GT-001" [Kernel] Port 0 : "GT-001 MIDI 1" (RWeX) Port 1 : "GT-001 MIDI 2" (RWeX) Port 2 : "GT-001 MIDI 3" (RWeX)
Dev Snd --------------------------------------------------- total 0 drwxr-xr-x 2 root root 120 Sep 21 11:17 by-id drwxr-xr-x 2 root root 140 Sep 21 11:17 by-path crw-rw----+ 1 root audio 116, 11 Sep 18 16:09 controlC0 crw-rw----+ 1 root audio 116, 2 Sep 18 16:09 controlC1 crw-rw----+ 1 root audio 116, 7 Sep 18 16:35 controlC2 crw-rw----+ 1 root audio 116, 13 Sep 18 16:09 controlC3 crw-rw----+ 1 root audio 116, 16 Sep 21 11:17 controlC4 crw-rw----+ 1 root audio 116, 10 Sep 18 16:35 midiC2D0 crw-rw----+ 1 root audio 116, 19 Sep 21 11:17 midiC4D0 crw-rw----+ 1 root audio 116, 12 Sep 21 11:17 pcmC0D0c crw-rw----+ 1 root audio 116, 4 Sep 21 11:17 pcmC1D0c crw-rw----+ 1 root audio 116, 3 Sep 21 11:17 pcmC1D0p crw-rw----+ 1 root audio 116, 6 Sep 21 11:17 pcmC1D1c crw-rw----+ 1 root audio 116, 5 Sep 21 11:17 pcmC1D1p crw-rw----+ 1 root audio 116, 9 Sep 21 11:17 pcmC2D0c crw-rw----+ 1 root audio 116, 8 Sep 21 11:17 pcmC2D0p crw-rw----+ 1 root audio 116, 15 Sep 21 11:17 pcmC3D0c crw-rw----+ 1 root audio 116, 14 Sep 21 11:17 pcmC3D0p crw-rw----+ 1 root audio 116, 18 Sep 21 11:17 pcmC4D0c crw-rw----+ 1 root audio 116, 17 Sep 21 11:17 pcmC4D0p crw-rw----+ 1 root audio 116, 1 Sep 18 16:09 seq crw-rw----+ 1 root audio 116, 33 Sep 18 16:09 timer
CPU ------------------------------------------------------- model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz cpu MHz : 3989.964
RAM ------------------------------------------------------- MemTotal: 18488420 kB SwapTotal: 12572668 kB
Hardware -------------------------------------------------- 03:00.0 VGA compatible controller: NVIDIA Corporation G96GL [Quadro FX 380] (rev a1)
Interupts ------------------------------------------------- CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 48811951 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 11 0 0 0 0 0 0 0 IO-APIC-edge i8042 8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi 12: 16 0 0 0 0 0 0 0 IO-APIC-edge i8042 16: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 5124556 163319 158327 437929 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb8, firewire_ohci 19: 325267 13896 83955 159958 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb7 21: 1036201 0 230710 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 23: 592782 25702 353849 1661163 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 66: 30 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 67: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 68: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 69: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 70: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 71: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 72: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 73: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 74: 115203 24153 263642 127794 0 0 0 0 PCI-MSI-edge ahci 75: 2767659 2074057 0 0 0 0 0 0 PCI-MSI-edge eth0 76: 1437112 1710820 1338068 1285065 0 0 0 0 PCI-MSI-edge ahci 77: 250289 0 0 0 0 0 0 0 PCI-MSI-edge nvidia NMI: 782 3470 3412 3600 25175 1900 1878 1889 Non-maskable interrupts LOC: 4034537 12008543 12954928 12367008 2650742 2731780 2831859 2820759 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 782 3470 3412 3600 25175 1900 1878 1889 Performance monitoring interrupts IWI: 5 0 2 0 0 0 0 0 IRQ work interrupts RTR: 17 17 0 0 0 0 0 0 APIC ICR read retries RES: 670617 339489 307088 285022 147590 176059 166329 156676 Rescheduling interrupts CAL: 59853 99019 93552 111099 79188 128309 92115 99425 Function call interrupts TLB: 587943 504015 516238 537952 386062 372979 395382 385494 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 488 486 486 486 486 486 486 486 Machine check polls HYP: 0 0 0 0 0 0 0 0 Hypervisor callback interrupts ERR: 0 MIS: 0
On Monday 21 Sep 2015 11:22:18 maillist@superlative.org wrote:
On Friday 18 Sep 2015 21:03:15 maillist@superlative.org wrote:
I recently got access to a Boss GT-001. This is a small USB audio Interface for guitar with onboard FX which doesn't work with ALSA under Linux Mint 17 (running kernel 3.16.0-38-generic).
<SNIP>
More follow up. I've upgraded the kernel to 4.0.0-040000-generic with no improvement. I've recompiled the usb sound modules with debug support and am getting the following. Note that I'm getting a probe failure with error code -5. Is there any reference anywhere for what these errors are?
Oct 5 13:51:47 KAMDesktop kernel: [ 910.443578] usb 3-1: new high-speed USB device number 6 using ehci-pci Oct 5 13:51:47 KAMDesktop kernel: [ 910.586067] usb 3-1: New USB device found, idVendor=0582, idProduct=0187 Oct 5 13:51:47 KAMDesktop kernel: [ 910.586071] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Oct 5 13:51:47 KAMDesktop kernel: [ 910.586073] usb 3-1: Product: GT-001 Oct 5 13:51:47 KAMDesktop kernel: [ 910.586075] usb 3-1: Manufacturer: BOSS Oct 5 13:51:47 KAMDesktop kernel: [ 910.586812] snd-usb-audio: probe of 3-1:1.0 failed with error -5 Oct 5 13:51:47 KAMDesktop kernel: [ 910.587438] ALSA stream.c:711 6:1:1: add audio endpoint 0xd Oct 5 13:51:47 KAMDesktop kernel: [ 910.587688] ALSA stream.c:711 6:2:1: add audio endpoint 0x8e Oct 5 13:51:47 KAMDesktop mtp-probe: checking bus 3, device 6: "/sys/devices/pci0000:00/0000:00:1a.7/usb3/3-1" Oct 5 13:51:47 KAMDesktop mtp-probe: bus: 3, device: 6 was not an MTP device Oct 5 13:51:47 KAMDesktop kernel: [ 910.588115] snd-usb-audio: probe of 3-1:1.3 failed with error -5 Oct 5 13:51:47 KAMDesktop kernel: [ 910.603135] ALSA pcm.c:376 setting usb interface 2:1 Oct 5 13:51:47 KAMDesktop kernel: [ 910.603138] ALSA endpoint.c:442 Creating new capture data endpoint #8e Oct 5 13:51:47 KAMDesktop kernel: [ 910.603160] ALSA endpoint.c:821 Setting params for ep #8e (type 0, 8 urbs), ret=0 Oct 5 13:51:47 KAMDesktop kernel: [ 910.606512] ALSA pcm.c:376 setting usb interface 1:1 Oct 5 13:51:47 KAMDesktop kernel: [ 910.606514] ALSA endpoint.c:442 Creating new playback data endpoint #d Oct 5 13:51:47 KAMDesktop kernel: [ 910.606517] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.606533] ALSA endpoint.c:821 Setting params for ep #d (type 0, 8 urbs), ret=0 Oct 5 13:51:47 KAMDesktop kernel: [ 910.606535] ALSA pcm.c:541 match_endpoint_audioformats: (fmt @ffff8804a98e9ca8) score 2 Oct 5 13:51:47 KAMDesktop kernel: [ 910.606538] ALSA endpoint.c:821 Setting params for ep #8e (type 0, 8 urbs), ret=0 Oct 5 13:51:47 KAMDesktop kernel: [ 910.606539] ALSA pcm.c:229 Starting data EP @ffff8803d6f54028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.606595] ALSA pcm.c:258 Starting sync EP @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.615766] ALSA pcm.c:376 setting usb interface 2:1 Oct 5 13:51:47 KAMDesktop kernel: [ 910.615779] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.615792] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.615821] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.615824] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.615842] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.615845] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.615980] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.615983] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.616078] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.616081] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.616490] ALSA pcm.c:376 setting usb interface 2:1 Oct 5 13:51:47 KAMDesktop kernel: [ 910.616492] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.616497] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.616512] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.616514] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.616530] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.616533] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.616629] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.616632] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.616754] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.616758] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.617110] ALSA pcm.c:376 setting usb interface 2:1 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617112] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617127] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.617155] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617158] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.617203] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617207] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.617358] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617361] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.617488] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617492] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.617895] ALSA pcm.c:376 setting usb interface 2:1 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617897] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617910] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.617943] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.617949] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.618005] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.618012] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.618192] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.618199] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.618354] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.618363] ALSA endpoint.c:786 Unable to change format on ep #8e: already in use Oct 5 13:51:47 KAMDesktop kernel: [ 910.623280] ALSA pcm.c:376 setting usb interface 1:1 Oct 5 13:51:47 KAMDesktop kernel: [ 910.623284] ALSA endpoint.c:434 Re-using EP d in iface 1,1 @ffff8803d6f54028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.623285] ALSA endpoint.c:434 Re-using EP 8e in iface 2,1 @ffff88041cb74028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.623308] ALSA endpoint.c:821 Setting params for ep #d (type 0, 8 urbs), ret=0 Oct 5 13:51:47 KAMDesktop kernel: [ 910.623310] ALSA pcm.c:541 match_endpoint_audioformats: (fmt @ffff8804a98e9ca8) score 2 Oct 5 13:51:47 KAMDesktop kernel: [ 910.623315] ALSA endpoint.c:821 Setting params for ep #8e (type 0, 8 urbs), ret=0 Oct 5 13:51:47 KAMDesktop kernel: [ 910.623316] ALSA pcm.c:229 Starting data EP @ffff8803d6f54028 Oct 5 13:51:47 KAMDesktop kernel: [ 910.623398] ALSA pcm.c:258 Starting sync EP @ffff88041cb74028
On Mon, 5 Oct 2015, maillist@superlative.org wrote:
More follow up. I've upgraded the kernel to 4.0.0-040000-generic with no improvement. I've recompiled the usb sound modules with debug support and am getting the following. Note that I'm getting a probe failure with error code -5. Is there any reference anywhere for what these errors are?
-5 would be an ordinary -E<foo> error code, looking in /usr/include/asm-generic/errno-base.h (ultimately from the kernel's uapi/asm-generic/errno-base.h) it would seem to be EIO (I/O error). Note too informative, but at least it'll stem from some 'return -EIO' or similar somewhere in the code. Must be some underlying function that is having problems.
Oct 5 13:51:47 KAMDesktop kernel: [ 910.586812] snd-usb-audio: probe of 3-1:1.0 failed with error -5
/Ricard
On Monday 05 Oct 2015 16:38:55 Ricard Wanderlof wrote: error code -5. Is there any reference anywhere for what these errors are?
-5 would be an ordinary -E<foo> error code, looking in /usr/include/asm-generic/errno-base.h (ultimately from the kernel's uapi/asm-generic/errno-base.h) it would seem to be EIO (I/O error). Note too informative, but at least it'll stem from some 'return -EIO' or similar somewhere in the code. Must be some underlying function that is having problems.
Ah, OK, that would explain why I couldn't grep it in the alsa codebase.
Cheers,
Keith
OK, so it seems that this hardware is substantially the same as the GT-100 which has previously (and recently) been raised as a problem on ALSA.
Clemens Ladisch wrote:
Aaron Spike wrote:
On Sat, Jan 10, 2015 at 2:41 PM, Clemens Ladisch wrote:
There is something that cannot be derived from the descriptors.
In a nutshell, what would someone who knew what they were doing do in this situation?
- Use some USB sniffer to find out what commands the Windows driver sends.
- Reverse engineer the firmware.
I'm going to attempt to capture some USB data using this device in Windows. If I do this, is there an accepted method for uploading the capture so it can be posted here?
At this point, I'm not 100% sure what the capture format is going to be...
Cheers,
Keith
On Tue, 6 Oct 2015, Keith A. Milner wrote:
OK, so it seems that this hardware is substantially the same as the GT-100 which has previously (and recently) been raised as a problem on ALSA.
Clemens Ladisch wrote:
Aaron Spike wrote:
On Sat, Jan 10, 2015 at 2:41 PM, Clemens Ladisch wrote:
There is something that cannot be derived from the descriptors.
In a nutshell, what would someone who knew what they were doing do in this situation?
- Use some USB sniffer to find out what commands the Windows driver sends.
- Reverse engineer the firmware.
I'm going to attempt to capture some USB data using this device in Windows. If I do this, is there an accepted method for uploading the capture so it can be posted here?
At this point, I'm not 100% sure what the capture format is going to be...
I just went down this road while researching the Zoom R16. There's a Windows application called USBPCap which can sniff an USB bus and dump packets in .pcap format. A reasonally recent version of Wireshark can then be used to analyze the data, as it supports the USBPCap output format from a certain version (FWIW, the version of Wireshark included with Debian Jessie works fine).
The corresponding dumps on Linux can be done by loading the usbmon module into the kernel. This allows Wireshark to sniff the USB buses.
I learned though that although Wireshark is happy reading the .pcap files produced by USBPCap, the resulting dumps can look quite different from what Wireshark sniffs in Linux, which initially took me aback. At least when it comes to USBPcap I think the reason is that the program actually sniffs the data halfway up (if not at the top of) the Windows protocol stack, meaning that there's data in the dump that does not actually occur on the wire. I'm not sure at what level usbmon sniffs, but it looks closer to what I'd expect on the physical cable.
In practice, all data is there in both cases, but it takes a bit of practice to actually compare the two successfully. Especially when it comes to isochronous packets (used for audio data transfer), the USBPcap format decodes the individual packets, whereas a dump generated via usbmon just delivered one large blob of data, which included both the isochronous packet headers and associated payload. Perhaps a more recent Wireshark might fare better; at the time the level of detail was sufficient for me so I didn't pursue it any further.
/Ricard
On Wednesday 07 Oct 2015 10:09:14 Ricard Wanderlof wrote:
On Tue, 6 Oct 2015, Keith A. Milner wrote:
OK, so it seems that this hardware is substantially the same as the GT-100 which has previously (and recently) been raised as a problem on ALSA.
I'm going to attempt to capture some USB data using this device in Windows. If I do this, is there an accepted method for uploading the capture so it can be posted here?
At this point, I'm not 100% sure what the capture format is going to be...
<Various snips>
I learned though that although Wireshark is happy reading the .pcap files produced by USBPCap, the resulting dumps can look quite different from what Wireshark sniffs in Linux, which initially took me aback. At least when it comes to USBPcap I think the reason is that the program actually sniffs the data halfway up (if not at the top of) the Windows protocol stack, meaning that there's data in the dump that does not actually occur on the wire. I'm not sure at what level usbmon sniffs, but it looks closer to what I'd expect on the physical cable.
Thanks Richard.
The data I'm getting from Wireshark via USBMon seems OK from my initial viewing. Incidentally, Wireshark can sniff directly from usbmon interfaces and exposes them as capture interfaces (at least with the version I have).
Here's an example of what I'm getting (exported as CSV): "No.","Time","Source","Destination","Protocol","Length","Info","Leftover Capture Data","Comment" "1","0.000000000","host","7.0","USB","64","GET DESCRIPTOR Request DEVICE","","This was from within Linux before I connected the USB device to the Windows VM guest" "2","0.000203000","7.0","host","USB","82","GET DESCRIPTOR Response DEVICE","","This was from within Linux before I connected the USB device to the Windows VM guest" "3","6.343942000","host","7.0","USB","64","SET INTERFACE Request","","" "4","6.344069000","7.0","host","USB","64","SET INTERFACE Response","","" "5","6.545252000","host","0.0","USB","64","SET ADDRESS Request","","" "6","6.564886000","host","7.0","USB","64","GET DESCRIPTOR Request DEVICE","","" "7","6.565099000","7.0","host","USB","82","GET DESCRIPTOR Response DEVICE","","" "8","6.565134000","host","7.0","USB","64","GET DESCRIPTOR Request CONFIGURATION","","" "9","6.565566000","7.0","host","USB","240","GET DESCRIPTOR Response CONFIGURATION","",""
The isochronous data appears as follows:
"54","24.767751000","host","7.14","USB","192","URB_ISOCHRONOUS in","eeffffff000000007000000000000000eeffffff70000000...",""
Wireshark also appears to decode them quite nicely. I've pasted one of the GET DESCRIPTOR responses below.
Now I need to try and work out what it all means...
Cheers,
Keith
GET DESCRIPTOR response decode:
No. Time Source Destination Length Info Leftover Capture Data Comment 9 6.565566000 7.0 host 240 GET DESCRIPTOR Response CONFIGURATION
Frame 9: 240 bytes on wire (1920 bits), 240 bytes captured (1920 bits) on interface 0 Interface id: 0 (usbmon3) Encapsulation type: USB packets with Linux header and padding (115) Arrival Time: Oct 6, 2015 22:11:10.987080000 BST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1444165870.987080000 seconds [Time delta from previous captured frame: 0.000432000 seconds] [Time delta from previous displayed frame: 0.000432000 seconds] [Time since reference or first frame: 6.565566000 seconds] Frame Number: 9 Frame Length: 240 bytes (1920 bits) Capture Length: 240 bytes (1920 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: usb] USB URB URB id: 0xffff880289c33740 URB type: URB_COMPLETE ('C') URB transfer type: URB_CONTROL (0x02) Endpoint: 0x80, Direction: IN 1... .... = Direction: IN (1) .000 0000 = Endpoint value: 0 Device: 7 URB bus id: 3 Device setup request: not relevant ('-') Data: present (0) URB sec: 1444165870 URB usec: 987080 URB status: Success (0) URB length [bytes]: 176 Data length [bytes]: 176 [Request in: 8] [Time from request: 0.000432000 seconds] Unused Setup Header Interval: 0 Start frame: 0 Copy of Transfer Flags: 0x00000200 Number of ISO descriptors: 0 CONFIGURATION DESCRIPTOR bLength: 9 bDescriptorType: 0x02 (CONFIGURATION) wTotalLength: 176 bNumInterfaces: 4 bConfigurationValue: 1 iConfiguration: 0 Configuration bmAttributes: 0xc0 SELF-POWERED NO REMOTE-WAKEUP 1... .... = Must be 1: Must be 1 for USB 1.1 and higher .1.. .... = Self-Powered: This device is SELF-POWERED ..0. .... = Remote Wakeup: This device does NOT support remote wakeup bMaxPower: 0 (0mA) INTERFACE DESCRIPTOR (0.0): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 0 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0xff bInterfaceProtocol: 0x00 iInterface: 0 INTERFACE DESCRIPTOR (1.0): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) bInterfaceNumber: 1 bAlternateSetting: 0 bNumEndpoints: 0 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x02 bInterfaceProtocol: 0x02 iInterface: 0 UNKNOWN DESCRIPTOR bLength: 6 bDescriptorType: 0x24 (unknown) INTERFACE DESCRIPTOR (1.1): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) bInterfaceNumber: 1 bAlternateSetting: 1 bNumEndpoints: 1 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x02 bInterfaceProtocol: 0x02 iInterface: 0 UNKNOWN DESCRIPTOR bLength: 7 bDescriptorType: 0x24 (unknown) UNKNOWN DESCRIPTOR bLength: 11 bDescriptorType: 0x24 (unknown) ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x0d OUT Endpoint:13 0... .... = Direction: OUT Endpoint .... 1101 = Endpoint Number: 0x0d bmAttributes: 0x05 .... ..01 = Transfertype: Isochronous-Transfer (0x01) .... 01.. = Synchronisationtype: Asynchronous (0x01) ..00 .... = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 112 ...0 0... .... .... = Transactions per microframe: 1 (0) .... ..00 0111 0000 = Maximum Packet Size: 112 bInterval: 1 UNKNOWN DESCRIPTOR bLength: 7 bDescriptorType: 0x25 (unknown) INTERFACE DESCRIPTOR (2.0): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) bInterfaceNumber: 2 bAlternateSetting: 0 bNumEndpoints: 0 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x02 bInterfaceProtocol: 0x01 iInterface: 0 INTERFACE DESCRIPTOR (2.1): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) bInterfaceNumber: 2 bAlternateSetting: 1 bNumEndpoints: 1 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x02 bInterfaceProtocol: 0x01 iInterface: 0 UNKNOWN DESCRIPTOR bLength: 7 bDescriptorType: 0x24 (unknown) UNKNOWN DESCRIPTOR bLength: 11 bDescriptorType: 0x24 (unknown) ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x8e IN Endpoint:14 1... .... = Direction: IN Endpoint .... 1110 = Endpoint Number: 0x0e bmAttributes: 0x25 .... ..01 = Transfertype: Isochronous-Transfer (0x01) .... 01.. = Synchronisationtype: Asynchronous (0x01) ..10 .... = Behaviourtype: Implicit Feedback-Data-Endpoint (0x02) wMaxPacketSize: 112 ...0 0... .... .... = Transactions per microframe: 1 (0) .... ..00 0111 0000 = Maximum Packet Size: 112 bInterval: 1 UNKNOWN DESCRIPTOR bLength: 7 bDescriptorType: 0x25 (unknown) INTERFACE DESCRIPTOR (3.0): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) bInterfaceNumber: 3 bAlternateSetting: 0 bNumEndpoints: 2 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x03 bInterfaceProtocol: 0x00 iInterface: 0 UNKNOWN DESCRIPTOR bLength: 6 bDescriptorType: 0x24 (unknown) ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x03 OUT Endpoint:3 0... .... = Direction: OUT Endpoint .... 0011 = Endpoint Number: 0x03 bmAttributes: 0x02 .... ..10 = Transfertype: Bulk-Transfer (0x02) .... 00.. = Synchronisationtype: No Sync (0x00) ..00 .... = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 .... ..10 0000 0000 = Maximum Packet Size: 512 bInterval: 1 ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x84 IN Endpoint:4 1... .... = Direction: IN Endpoint .... 0100 = Endpoint Number: 0x04 bmAttributes: 0x02 .... ..10 = Transfertype: Bulk-Transfer (0x02) .... 00.. = Synchronisationtype: No Sync (0x00) ..00 .... = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 .... ..10 0000 0000 = Maximum Packet Size: 512 bInterval: 0 INTERFACE DESCRIPTOR (3.1): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) bInterfaceNumber: 3 bAlternateSetting: 1 bNumEndpoints: 2 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x03 bInterfaceProtocol: 0x00 iInterface: 0 ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x03 OUT Endpoint:3 0... .... = Direction: OUT Endpoint .... 0011 = Endpoint Number: 0x03 bmAttributes: 0x03 .... ..11 = Transfertype: Interrupt-Transfer (0x03) .... 00.. = Synchronisationtype: No Sync (0x00) ..00 .... = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 ...0 0... .... .... = Transactions per microframe: 1 (0) .... ..10 0000 0000 = Maximum Packet Size: 512 bInterval: 1 ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: 0x05 (ENDPOINT) bEndpointAddress: 0x85 IN Endpoint:5 1... .... = Direction: IN Endpoint .... 0101 = Endpoint Number: 0x05 bmAttributes: 0x03 .... ..11 = Transfertype: Interrupt-Transfer (0x03) .... 00.. = Synchronisationtype: No Sync (0x00) ..00 .... = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 ...0 0... .... .... = Transactions per microframe: 1 (0) .... ..10 0000 0000 = Maximum Packet Size: 512 bInterval: 1
On Wed, 7 Oct 2015, Keith A. Milner wrote:
The data I'm getting from Wireshark via USBMon seems OK from my initial viewing. Incidentally, Wireshark can sniff directly from usbmon interfaces and exposes them as capture interfaces (at least with the version I have).
Same here. I might have been unclear in my previous message, but that is what I meant.
The isochronous data appears as follows:
"54","24.767751000","host","7.14","USB","192","URB_ISOCHRONOUS
Yes, these are the isochronous packet headers.
in","eeffffff 00000000 70000000 00000000 eeffffff 70000000...",""
-------- -------- -------- -------- tag ? offset length status and again (next header)
My understanding is that the isochronous data is sent one packet per frame on the wire (interval: 1 ms for full speed, 125 µs (actually called a microframe) for high speed) but delivering the data one packet at a time to the USB application would result in a lot of packet transfers, so isochronous data is lumped together and delivered at some more or less regular interval to the higher layers. So at USB API (or Wireshark) layer you get these 'isochronous' packets which list a bunch of headers followed by the corresponding data as a single 'packet', even though it's been assembled from several distinct ones. The 'offset' fields are relative to the end of the headers in the resulting packet, where the actual isochronous data starts.
Wireshark also appears to decode them quite nicely. I've pasted one of the GET DESCRIPTOR responses below. ... DESCRIPTOR Response CONFIGURATION
Frame 9: 240 bytes on wire (1920 bits), 240 bytes captured (1920 bits) on interface 0 ... iInterface: 0 UNKNOWN DESCRIPTOR bLength: 6 bDescriptorType: 0x24 (unknown) INTERFACE DESCRIPTOR (1.1): class Vendor Specific bLength: 9 bDescriptorType: 0x04 (INTERFACE) ...
Actually, you should be able to get the configuration information directly in Linux by using 'lsusb -v'. It lists the 'Unknown descriptors' in their entirety in hex (prefixed by 'UNRECOGNIZED:') so that you can decode them separately without having to examine the actual binary packet content in Wireshark.
/Ricard
On Wednesday 07 Oct 2015 17:20:39 Ricard Wanderlof wrote:
Actually, you should be able to get the configuration information directly in Linux by using 'lsusb -v'. It lists the 'Unknown descriptors' in their entirety in hex (prefixed by 'UNRECOGNIZED:') so that you can decode them separately without having to examine the actual binary packet content in Wireshark.
Yep, already done this (see my first post in this thread). I posted this as an example of Wireshark's decoding of the non-isochronous packets.
Cheers,
Keith
On Tuesday 06 Oct 2015 20:58:01 Keith A. Milner wrote:
OK, so it seems that this hardware is substantially the same as the GT-100 which has previously (and recently) been raised as a problem on ALSA.
I'm getting somewhere...
With the following quirk I am getting audio playback with aplay. I have what seems like correct MIDI interfaces working (although not fully tested).
However, recording does not seem to work.
{ /* Boss GT-001 Guitar Interface */ USB_DEVICE(0x0582, 0x0187), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Boss", .product_name = "GT-001", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_IGNORE_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S32_LE, .channels = 4, .iface = 1, .altsetting = 1, .altset_idx = 1, .endpoint = 0x0d, .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_44100, .rate_min = 44100, .rate_max = 44100, .nr_rates = 1, .rate_table = (unsigned int[]) { 44100 } } }, { .ifnum = 2, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S32_LE, .channels = 4, .iface = 2, .altsetting = 1, .altset_idx = 1, .endpoint = 0x8e, .ep_attr = 0x25, .rates = SNDRV_PCM_RATE_44100, .rate_min = 44100, .rate_max = 44100, .nr_rates = 1, .rate_table = (unsigned int[]) { 44100 } } }, { .ifnum = 3, .type = QUIRK_MIDI_ROLAND }, { .ifnum = 4, .type = QUIRK_IGNORE_INTERFACE }, { .ifnum = -1 } } } },
Cheers,
Keith
On Thursday 08 Oct 2015 01:51:20 Keith A. Milner wrote:
On Tuesday 06 Oct 2015 20:58:01 Keith A. Milner wrote:
OK, so it seems that this hardware is substantially the same as the GT-100 which has previously (and recently) been raised as a problem on ALSA.
I'm getting somewhere...
With the following quirk I am getting audio playback with aplay. I have what seems like correct MIDI interfaces working (although not fully tested).
However, recording does not seem to work.
I should add that, by "does not seem to work", the interface is seen, but nothing records. When using audacity, for instance, the playhead seems to get stuck and doesn't advance.
Cheers,
Keith
On Thu, 8 Oct 2015, Keith A. Milner wrote:
On Thursday 08 Oct 2015 01:51:20 Keith A. Milner wrote:
On Tuesday 06 Oct 2015 20:58:01 Keith A. Milner wrote:
OK, so it seems that this hardware is substantially the same as the GT-100 which has previously (and recently) been raised as a problem on ALSA.
I'm getting somewhere...
With the following quirk I am getting audio playback with aplay. I have what seems like correct MIDI interfaces working (although not fully tested).
However, recording does not seem to work.
I should add that, by "does not seem to work", the interface is seen, but nothing records. When using audacity, for instance, the playhead seems to get stuck and doesn't advance.
How does it look in Wireshark? Does the isochronous transfer for the capture direction start?
Actually, looking at your lsusb -v dump of the GT-001, I notice the following:
Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0070 1x 112 bytes bInterval 1
Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0070 1x 112 bytes bInterval 1
When the Isochronous Synch Type is Asynchronous, there must be a feedback channel where the USB device reports back information so that it can adjust the output sampling rate (http://wiki.osdev.org/Universal_Serial_Bus#Asynchronous_Endpoints).
I might be barking up the wrong tree here as I'm new to this, but it looks as if endpoint 0x8e is providing the feedback data, and there doesn't seem to be any other isochronous endpoint defined in the lsusb dump which could be used for the actual capture cdata.
I'm not sure what 'Implicit feedback Data' means exactly though - is the feedback data multiplexed with the capture data perhaps?
/Ricard
On Thursday 08 Oct 2015 09:02:22 Ricard Wanderlof wrote:
When the Isochronous Synch Type is Asynchronous, there must be a feedback channel where the USB device reports back information so that it can adjust the output sampling rate (http://wiki.osdev.org/Universal_Serial_Bus#Asynchronous_Endpoints).
I might be barking up the wrong tree here as I'm new to this, but it looks as if endpoint 0x8e is providing the feedback data, and there doesn't seem to be any other isochronous endpoint defined in the lsusb dump which could be used for the actual capture cdata.
I'm not sure what 'Implicit feedback Data' means exactly though - is the feedback data multiplexed with the capture data perhaps?
I'm quite new to this too, but here is my interpretation.
Implicit feedback means "assumed" and, hence, there is actually no feedback channel. That would be "explicit feedback".
This seems to be backed up by the article you linked:
"Asynchronous source endpoints imply their data rate by the number of samples produced per (micro)frame. "
In this case the endpoint is an IN (with respect to the host) and so the rate is controlled by the GT-001's clock, and communicated to the host via the samples per microframe (wMaxPacketSize?) and it is the host's job to keep up with that.
On the other hand, playback data is different. According to the article:
"Asynchronous sink endpoints must provide explicit feedback to the source endpoint. When the source endpoint is the host, it is the responsibility of the device driver to process the explicit feedback properly. This feedback allows the host and device to make slight adjustments to the data rate in order to compensate for any clock drift."
So async playback (OUT) devices *do* seem to need explicit feedback.
My reading of the Interface descriptor data for the GT-001 is as follows:
Interface 1 has an OUT (playback) endpoint number 13 which is Isochronous and Asynchronous. The implications is explicit feedback is required from the device to the host to control the output rate.
Interface 2 has an IN (record) endpoint number 14 which is Isochronous and Asynchronous and uses implicit feedback, so no feedback channel is required.
Interface 3 is MIDI, comprising IN and OUT bulk data endpoints and IN and OUT interrupt endpoints. Note that this is a Roland MIDI Interface which has a specific quirk, where the endpoints contain multiple MIDI channels as specified by the Vendor specific CS_INTERFACE data:
** UNRECOGNIZED: 06 24 f1 02 03 03
This can be read as: Field Value Description bLength 0x06 Size of this descriptor in bytes bDescriptorType 0x24 CS_INTERFACE bDescriptorSubtype 0xf1 Roland specific UNKNOWN 0x02 MIDI channels UNKNOWN 0x03 Number of input MIDI channels UNKNOWN 0x03 Number of output MIDI channels
So, in this case, there are 3 In and 3 OUT MIDI channels associated with this Interface.
However, these definitions don't seem to fully align with my configuration and, when I used those definitions in the quirk, playback didn't work. I guess it's entirely possible the attributes in the descriptor are complete rubbish.
I have some usbmon dumps which I will try to find time to analyze.
Cheers,
Keith
On Thursday 08 Oct 2015 12:51:54 Keith A. Milner wrote:
I have some usbmon dumps which I will try to find time to analyze.
Well the results of my packet dumps were interesting.
For audio playback, I noticed the Windows drive seemed to enable the IN endpoint (EP 14) as well as the OUT one (EP 13). This seemed to match with the view that explicit feedback is required for asynchronous host-to-device transfers.
So I've changed the quirk as follows, which appears to work for playback still:
.ep_attr = 0x15,
This is USB_ENDPOINT_USAGE_FEEDBACK + USB_ENDPOINT_SYNC_ASYNC + USB_ENDPOINT_XFER_ISOC
I say works "still" because the previous value I had (0x01) worked as well. However, this was basically setting the sync type to NONE instead of ASYNC, and didn't configure any feedback type. This was probably free-running and, effectively, similar to "ADAPTIVE", but is probably prone to occasional sync problems/buffer overflows on the device.
The resulting usbmon dump seems to follow the one from Windows now.
Input is still a problem!
Under ALSA, the input stream (via URB_ISOCHRONOUS in requests/responses) to IN endpoint 14 seems to be working. However, under Windows the driver also initiates the OUT endpoint 13 which then has an output stream (via URB_ISOCHRONOUS out requests/responses).
I don't know if this is required by the device for some reason (explicit feedback, although that doesn't make much sense to me?) or if it's just something irrelevant that the Windows driver happens to do.
Either way, Linux seems to get stuck with the input data (for instance, the playhead in Audacity doesn't move).
Cheers,
Keith
Ricard Wanderlof wrote:
bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0070 1x 112 bytes bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0070 1x 112 bytesWhen the Isochronous Synch Type is Asynchronous, there must be a feedback channel where the USB device reports back information so that it can adjust the output sampling rate.
I might be barking up the wrong tree here as I'm new to this, but it looks as if endpoint 0x8e is providing the feedback data, and there doesn't seem to be any other isochronous endpoint defined in the lsusb dump which could be used for the actual capture cdata.
The first endpoint in an audio interface is for the actual samples.
I'm not sure what 'Implicit feedback Data' means exactly though - is the feedback data multiplexed with the capture data perhaps?
The USB 2.0 specification says: | 5.12.4.3 Implicit Feedback | | In some cases, implementing a separate explicit feedback endpoint can | be avoided. If a device implements a group of isochronous data | endpoints that are closely related and if: | ⢠All the endpoints in the group are synchronized (i.e. use sample | clocks that are derived from a common master clock) | ⢠The group contains one or more isochronous data endpoints in one | direction that normally would need explicit feedback | ⢠The group contains at least one isochronous data endpoint in the | opposite direction | Under these circumstances, the device may elect not to implement | a separate isochronous explicit feedback endpoint. Instead, feedback | information can be derived from the data endpoint in the opposite | direction by observing its data rate.
In theory, the driver supports this, but there are known to be some bugs. And in any case there should be no problem getting the capture stream to start (it's the playback stream that would have a slightly wrong sample clock); it's possible that this device needs some vendor- specific commands, or a different order of commands. (The interesting USB transactions would be everything except the isochronous ones.)
Regards, Clemens
On Thursday 08 Oct 2015 15:54:46 Clemens Ladisch wrote:
In theory, the driver supports this, but there are known to be some bugs. And in any case there should be no problem getting the capture stream to start (it's the playback stream that would have a slightly wrong sample clock);
Thanks Clemens,
That was my reading of it too. My latest quirk tests for playback use explicit feedback, which seems to mirror what the Windows driver does.
I'm still having no luck with recording though.
it's possible that this device needs some vendor- specific commands, or a different order of commands. (The interesting USB transactions would be everything except the isochronous ones.)
I've been looking at the usbmon dumps I have of recording under Windows and I don't see anything that stands out, but I'll keep looking.
Cheers,
Keith
On Thursday 08 Oct 2015 15:10:03 Keith A. Milner wrote:
I've been looking at the usbmon dumps I have of recording under Windows and I don't see anything that stands out, but I'll keep looking.
If anyone else wants to take a look at these, I've uploaded the Usbmod captures to a dropbox folder:
https://www.dropbox.com/sh/zhh5ftklyjqmovj/AAAOVYO7hQQ_atrc2EcBKfbTa?dl=0
Cheers,
Keith
Forking this thread to focus on MIDI issues
This device has a single USB MIDI Interface on Interface 3, with 2 alternate settings, each with 2 endpoints as follows:
Interface 3 - Setting 0 - Endpoint 3 OUT Bulk Data - Endpoint 4 IN Bulk Data - Setting 1 - Endpoint 3 OUT Interrupt data - Endpoint 5 IN Interrupt data
My evaluation is that this is a new style of MIDI Interface from others previously encountered. Comparing, for instance, with the Roland V Synth GT which seems to have the following Interface layout:
Interface 2 - Setting 0 - Endpoint 3 OUT Bulk Data - Endpoint 4 IN Bulk Data - Setting 1 - Endpoint 3 OUT Bulk data - Endpoint 4 IN Interrupt data
The major difference is that the GT.001 has Interrupt Transfer modes for both IN and OUT.
Looking at snd_usbmidi_switch_roland_altsetting this sets the alternate setting so that the interrupt input endpoint is used. This routine looks for a pair of endpoints where the OUT endpoint is Bulk transfer, and the input is Interrupt transfer, and sets the mode accordingly. I've modified this to support Interrupt Xfer in both directions, and this seems to work (although my changes aren't read for publication yet as they are rather experimental and messy, and probably break the existing detection.
I'll try to fix this code and submit a patch.
Cheers,
Keith
participants (4)
-
Clemens Ladisch -
Keith A. Milner -
maillist＠superlative.org
-
Ricard Wanderlof