All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.