search

monome / ansible

http://monome.org/docs/ansible
GNU General Public License v2.0
67 stars 26 forks source link

Teensy MIDI device not recognized by ansible #63

Open okyeron opened 5 years ago

okyeron commented 5 years ago

Tried testing my TeensyLC based usbmidi host-to-host adapter with ansible tonight. Hoping to be able to get this working for norns->anisble midi communication.

So... Ansible crashes (becomes unresponsive) when this device is plugged in and requires power cycling to get it back. I tried grid and other working midi devices)

Notes:

Wanted to log this while it's fresh in my mind. Will update with debug once I can get things compiled with UHI_MIDI_PRINT_DBG turned on.

Also need to test with other Teensy variants (3.2/3.6) to see if they also do this.

okyeron commented 5 years ago

Midi debug session w #define UHI_MIDI_PRINT_DBG 1:

 uhi_midi_install ignoring descriptor; type: 0x00000002
 bLength : 0x00000009
 bInterfaceNumber : 0x00000000
 bAlternateSetting : 0x00000000
 bNumEndpoints : 0x00000002
 bInterfaceClass : 0x00000001
 bInterfaceSubClass : 0x00000003
 bInterfaceProtocol : 0x00000000
 iInterface : 0x00000000

 class/subclass matches audio/MIDI. 
 uhi_midi_install ignoring descriptor; type: 0x00000024
 uhi_midi_install ignoring descriptor; type: 0x00000024
 uhi_midi_install ignoring descriptor; type: 0x00000024
 uhi_midi_install ignoring descriptor; type: 0x00000024
 uhi_midi_install ignoring descriptor; type: 0x00000024
 allocating bulk endpoint (  output )
 uhi_midi_install ignoring descriptor; type: 0x00000025
 allocating bulk endpoint (  input )
 uhi_midi_install ignoring descriptor; type: 0x00000025
 bLength : 0x00000009
 bInterfaceNumber : 0x00000001
 bAlternateSetting : 0x00000000
 bNumEndpoints : 0x00000002
 bInterfaceClass : 0x00000003
 bInterfaceSubClass : 0x00000000
 bInterfaceProtocol : 0x00000000
 iInterface : 0x00000000

 uhi_midi_install ignoring interface; class: 0x00000003 ; subclass: 0x00000000
 uhi_midi_install ignoring descriptor; type: 0x00000021

at which point ansible becomes unresponsive. It does this consistently.

Any suggestions?

EDIT: FWIW - linux lsusb -v shows this corresponding info for those last few strings:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      33
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               2

so it seems to be barfing on the HID interface?

ngwese commented 5 years ago

As an experiment you might try removing the UHI_HID entry in this line: https://github.com/monome/libavr32/blob/554e31c465220a9b88098bcde3cf0802889c4a82/conf/conf_usb_host.h#L16 ...and rebuilding the firmware. I had thought the list of supported device types was being maintained separately for each device (trilogy, teleype, ansible) but it looks like the config is shared.

It could be that the code for the HID interface does something bad or is incomplete and this is just the first time someone has plugged in a HID capable device (and reported a problem).

scanner-darkly commented 5 years ago

shouldn't in theory cause issues as HID is used by teletype (and polyearthsea/multipass), but i wonder if this is because the device reports itself as both HID and MIDI.

okyeron commented 5 years ago

Some followup testing.

additional debug in libavr32/asf/avr32/drivers/usbb/usbb_host.c shows this when the lockup happens:

uhi_midi_install ignoring interface; class: 0x00000003 ; subclass: 0x00000000
 uhi_midi_install ignoring descriptor; type: 0x00000021-- uhd_setup_request
-- uhd_ctrl_phase_setup
-- uhd_interrupt 0 uhd_ctrl_interrupt
-- uhd_ctrl_phase_zlp_in
-- uhd_interrupt 0 uhd_ctrl_interrupt
-- uhd_ctrl_request_end
------- uhd_ep_run 1
-- uhd_pipe_trans_complet 1
.. more to transfer
.. in pipe
.. exit 1
------- uhd_ep_run job created

If I comment out UHI_HID in conf_usb_host.h I get a uhd_suspend at the end but no freeze-up.

uhi_midi_install ignoring interface; class: 0x00000003 ; subclass: 0x00000000
 uhi_midi_install ignoring descriptor; type: 0x00000021-- uhd_suspend

However, MIDI does not finish and midi from the teensy device is not received.

okyeron commented 5 years ago

A bit more testing...

Tried testing with Polyearthsea on Meadowphysics and errors are the same (with UHI_HID still active). However - with whatever is different in @scanner-darkly's version of libavr32 - it does not crash the module. It keeps working ok if I remove the teensy and plug something else in. But still no midi from the teensy.

okyeron commented 5 years ago

Testing again with most recent libavr32 updates.

results:

Going to add some debug again and see if I can track this down further

okyeron commented 5 years ago

Further testing and a breakthru... Digging around in uhi_midi.c

What seems to be happening is this....

as the bInterfaceClass's are being evaluated, iface_supported gets set to true if there's a midi interface, or false if not. However I think this loop currently assumes that there will be just one bInterfaceClass to evaluate. If another one (like an HID for the teensy) comes after the midi interface, then iface_supported gets set back to false and uhi_midi_dev.dev = dev; never happens.

So... as a test at line 166 I added the following to break out of the loop if it hits an HID device interface

        if (ptr_iface->bInterfaceClass == HID_CLASS){
            print_dbg("\r\n got HID");
            break;
        }

This seems to fix my problem - it finishes the midi install process and I get finished uhi_midi_enable

So then... Is my fix a good solution, or is there a better way to fix this?

EDIT - I have also commented out UHI_HID in conf_usb_host.h