* Boss GT-001
@ 2015-09-18 20:03 maillist
2015-09-21 10:22 ` maillist
2015-10-10 13:16 ` Boss GT-001 MIDI Keith A. Milner
0 siblings, 2 replies; 20+ messages in thread
From: maillist @ 2015-09-18 20:03 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-09-18 20:03 Boss GT-001 maillist
@ 2015-09-21 10:22 ` maillist
2015-10-05 13:43 ` maillist
2015-10-10 13:16 ` Boss GT-001 MIDI Keith A. Milner
1 sibling, 1 reply; 20+ messages in thread
From: maillist @ 2015-09-21 10:22 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-09-21 10:22 ` maillist
@ 2015-10-05 13:43 ` maillist
2015-10-05 14:38 ` Ricard Wanderlof
0 siblings, 1 reply; 20+ messages in thread
From: maillist @ 2015-10-05 13:43 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-05 13:43 ` maillist
@ 2015-10-05 14:38 ` Ricard Wanderlof
2015-10-05 14:46 ` maillist
0 siblings, 1 reply; 20+ messages in thread
From: Ricard Wanderlof @ 2015-10-05 14:38 UTC (permalink / raw)
To: maillist; +Cc: alsa-devel
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
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-05 14:38 ` Ricard Wanderlof
@ 2015-10-05 14:46 ` maillist
2015-10-06 19:58 ` Keith A. Milner
0 siblings, 1 reply; 20+ messages in thread
From: maillist @ 2015-10-05 14:46 UTC (permalink / raw)
To: alsa-devel; +Cc: Ricard Wanderlof
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-05 14:46 ` maillist
@ 2015-10-06 19:58 ` Keith A. Milner
2015-10-06 20:57 ` Keith A. Milner
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Keith A. Milner @ 2015-10-06 19:58 UTC (permalink / raw)
To: alsa-devel; +Cc: 'Clemens Ladisch'
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?
>
> 1. Use some USB sniffer to find out what commands the Windows driver sends.
> 2. 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-06 19:58 ` Keith A. Milner
@ 2015-10-06 20:57 ` Keith A. Milner
2015-10-07 8:09 ` Ricard Wanderlof
2015-10-08 0:51 ` Keith A. Milner
2 siblings, 0 replies; 20+ messages in thread
From: Keith A. Milner @ 2015-10-06 20:57 UTC (permalink / raw)
To: alsa-devel; +Cc: 'Clemens Ladisch'
On Tuesday 06 Oct 2015 20:58:01 Keith A. Milner wrote:
>
> At this point, I'm not 100% sure what the capture format is going to be...
I found a way to capture from a VM using USBMon and Wireshark.
Cheers,
Keith
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-06 19:58 ` Keith A. Milner
2015-10-06 20:57 ` Keith A. Milner
@ 2015-10-07 8:09 ` Ricard Wanderlof
2015-10-07 9:41 ` Keith A. Milner
2015-10-08 0:51 ` Keith A. Milner
2 siblings, 1 reply; 20+ messages in thread
From: Ricard Wanderlof @ 2015-10-07 8:09 UTC (permalink / raw)
To: Keith A. Milner; +Cc: alsa-devel, 'Clemens Ladisch'
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?
> >
> > 1. Use some USB sniffer to find out what commands the Windows driver sends.
> > 2. 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
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-07 8:09 ` Ricard Wanderlof
@ 2015-10-07 9:41 ` Keith A. Milner
2015-10-07 15:20 ` Ricard Wanderlof
0 siblings, 1 reply; 20+ messages in thread
From: Keith A. Milner @ 2015-10-07 9:41 UTC (permalink / raw)
To: alsa-devel; +Cc: 'Clemens Ladisch', Ricard Wanderlof
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-07 9:41 ` Keith A. Milner
@ 2015-10-07 15:20 ` Ricard Wanderlof
2015-10-07 16:31 ` Keith A. Milner
0 siblings, 1 reply; 20+ messages in thread
From: Ricard Wanderlof @ 2015-10-07 15:20 UTC (permalink / raw)
To: Keith A. Milner; +Cc: alsa-devel
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
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-07 15:20 ` Ricard Wanderlof
@ 2015-10-07 16:31 ` Keith A. Milner
0 siblings, 0 replies; 20+ messages in thread
From: Keith A. Milner @ 2015-10-07 16:31 UTC (permalink / raw)
To: alsa-devel; +Cc: Ricard Wanderlof
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-06 19:58 ` Keith A. Milner
2015-10-06 20:57 ` Keith A. Milner
2015-10-07 8:09 ` Ricard Wanderlof
@ 2015-10-08 0:51 ` Keith A. Milner
2015-10-08 0:54 ` Keith A. Milner
2 siblings, 1 reply; 20+ messages in thread
From: Keith A. Milner @ 2015-10-08 0:51 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-08 0:51 ` Keith A. Milner
@ 2015-10-08 0:54 ` Keith A. Milner
2015-10-08 7:02 ` Ricard Wanderlof
0 siblings, 1 reply; 20+ messages in thread
From: Keith A. Milner @ 2015-10-08 0:54 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-08 0:54 ` Keith A. Milner
@ 2015-10-08 7:02 ` Ricard Wanderlof
2015-10-08 11:51 ` Keith A. Milner
2015-10-08 13:54 ` Clemens Ladisch
0 siblings, 2 replies; 20+ messages in thread
From: Ricard Wanderlof @ 2015-10-08 7:02 UTC (permalink / raw)
To: Keith A. Milner; +Cc: alsa-devel
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
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-08 7:02 ` Ricard Wanderlof
@ 2015-10-08 11:51 ` Keith A. Milner
2015-10-08 14:03 ` Keith A. Milner
2015-10-08 13:54 ` Clemens Ladisch
1 sibling, 1 reply; 20+ messages in thread
From: Keith A. Milner @ 2015-10-08 11:51 UTC (permalink / raw)
To: alsa-devel; +Cc: Ricard Wanderlof
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-08 7:02 ` Ricard Wanderlof
2015-10-08 11:51 ` Keith A. Milner
@ 2015-10-08 13:54 ` Clemens Ladisch
2015-10-08 14:10 ` Keith A. Milner
1 sibling, 1 reply; 20+ messages in thread
From: Clemens Ladisch @ 2015-10-08 13:54 UTC (permalink / raw)
To: Ricard Wanderlof, Keith A. Milner; +Cc: alsa-devel
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 bytes
>
> 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.
>
> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-08 11:51 ` Keith A. Milner
@ 2015-10-08 14:03 ` Keith A. Milner
0 siblings, 0 replies; 20+ messages in thread
From: Keith A. Milner @ 2015-10-08 14:03 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-08 13:54 ` Clemens Ladisch
@ 2015-10-08 14:10 ` Keith A. Milner
2015-10-08 14:34 ` Keith A. Milner
0 siblings, 1 reply; 20+ messages in thread
From: Keith A. Milner @ 2015-10-08 14:10 UTC (permalink / raw)
To: Clemens Ladisch, Ricard Wanderlof; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001
2015-10-08 14:10 ` Keith A. Milner
@ 2015-10-08 14:34 ` Keith A. Milner
0 siblings, 0 replies; 20+ messages in thread
From: Keith A. Milner @ 2015-10-08 14:34 UTC (permalink / raw)
To: alsa-devel; +Cc: Ricard Wanderlof, Clemens Ladisch
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Boss GT-001 MIDI
2015-09-18 20:03 Boss GT-001 maillist
2015-09-21 10:22 ` maillist
@ 2015-10-10 13:16 ` Keith A. Milner
1 sibling, 0 replies; 20+ messages in thread
From: Keith A. Milner @ 2015-10-10 13:16 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-10-10 13:16 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-18 20:03 Boss GT-001 maillist
2015-09-21 10:22 ` maillist
2015-10-05 13:43 ` maillist
2015-10-05 14:38 ` Ricard Wanderlof
2015-10-05 14:46 ` maillist
2015-10-06 19:58 ` Keith A. Milner
2015-10-06 20:57 ` Keith A. Milner
2015-10-07 8:09 ` Ricard Wanderlof
2015-10-07 9:41 ` Keith A. Milner
2015-10-07 15:20 ` Ricard Wanderlof
2015-10-07 16:31 ` Keith A. Milner
2015-10-08 0:51 ` Keith A. Milner
2015-10-08 0:54 ` Keith A. Milner
2015-10-08 7:02 ` Ricard Wanderlof
2015-10-08 11:51 ` Keith A. Milner
2015-10-08 14:03 ` Keith A. Milner
2015-10-08 13:54 ` Clemens Ladisch
2015-10-08 14:10 ` Keith A. Milner
2015-10-08 14:34 ` Keith A. Milner
2015-10-10 13:16 ` Boss GT-001 MIDI Keith A. Milner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.