Hybrid USB MIDI devices not recognised

[doughadfield]

Hi, the midi2usbhost does not recognise the following devices, which are supposed to have a class compliant MIDI USB profile, but as part of multiple other profiles (USB audio, etc):
Line6 HX Stomp
Line6 Pod Go

My objective in building the midi2usbhost project is to connect wired MIDI to my Pod Go, as this only has USB MIDI connection. I have sucessfully connected the Pod Go via a Raspberry Pi Zero running Linux, using the ttymidi-sysex driver to pass traffic between the USB Pod Go and wired MIDI on the UART. However I would very much like to get this going with a Pico, for lots of reliability and simplicity reasons.

The MIDI descriptor for the Pod Go (as dumped from Linux) is included below. As can be seen, it's large and complex, but we're only interested in the MIDI piece, which is supposed to be class compliant. What's the chance of being able to support this device with midi2usbhost?

thanks again

Doug

podgo-descriptor.txt

[doughadfield]

Further to the above, following advice on the README.md of the project I increased the CFG_TUH_ENUMERATION_BUFSIZE in increments right up to 4096, with no change to behaviour (no output at all on the UART0 debug serial port when USB cable from the Pod Go is inserted or removed). I tested with the NanoKontrol2 at each buffer size change and it is immediately recognised when plugged in, and a message printed when removed.
I added up the apparent descriptor section sizes and it doesn't appear to come close to the original 512byte total, so this was grasping at straws a bit, but I thought the test had do be done. I suspect that the name of the MIDI section of the descriptor differs in some way from a basic class compliant MIDI descriptor, so there needs to be an additional OR test in the code, but I can't find the place at the moment.

[doughadfield]

I've set the tinyusb debug log level to 2 and it looks like this is a tinyusb library issue - the driver is not found for the MIDI section of the usb descriptor. I've therefore opened a case in the https://github.com/hathach/tinyusb repo (case 3159)

[rppicomidi]

@doughadfield Be careful increasing memory size. The RP2040 does not have the memory of larger Raspberry Pi boards.
If you wish, you can try to go back to an older version of TinyUSB that builds with the usb_midi_host driver. Others have had success enumerating composite audio and MIDI devices. Just build the C-code example project. If that works, you can go back to a previous version of this project that uses my MIDI Host driver and all should be fine.

[rppicomidi]

@doughadfield I took a closer look at the POD Go descriptor dump you sent. An older version of this code that uses the usb_midi_host driver should work for you. I posted a comment on hathach/tinyusb#3159, too.

[doughadfield]

Thank you so much!! - I'll try that at the weekend and let you know how I get on.

[doughadfield]

Hi again @rppicomidi when you say "an older version of this code" do you mean this project (midi2usbhost) or the tinyUSB library? I can't see a way to cleanly download an earlier version of this project, as there aren't any releases to go back through. If I download an earlier version of the tinyusb lib, what do I need to do in this project to support the earlier version of tinyusb?

[rppicomidi]

Sorry if I was not clear. The shortest path to what you want is to revert this project to before I started using the TinyUSB native driver and still used the usb_midi_host driver. I am going to explain how to figure that out in detail next. However, if you are going to be working in this space, it is probably worth your time to study how to use git to go back revisions and to manage git submodules. TinyUSB Host code changes frequently and sometimes breaks old APIs.

1. Go to the midi2usbhost project web site.
2. Click the Commits text. It will take you here
3. Find the commit right before the "Integrate TinyUSB native USB MIDI host driver" commit. This is the last commit I made that still used my usb_midi_host driver. It has git hash 45c5982
4. Open a command line window
5. Change directory to where you cloned the midi2usbhost project
6. Type the following commands

git checkout 45c5982
git submodule update --recursive --init

Now your source code will use my driver, not the TinyUSB MIDI Host driver. Note that you could have used the git log command to find the commit you needed to check out instead of using the GitHub website, but I wasn't sure how much you knew.

Next, you will have to check out an earlier version of TinyUSB because the version of TinyUSB that added native MIDI Host support broke my driver. If you are using VS Code and the Pico SDK plugin, you will have to find where the SDK is getting TinyUSB and fix it up there. See the Update TinyUSB section of the C-Code README.md file for more information. Commit 29ffd57 is the commit right before MIDI Host support was added. I found it using git log and searched the log, but a slog through the TinyUSB GitHub site would have worked too.

cd ${PICO_SDK_PATH}/lib/tinyusb
git checkout 29ffd57

Build and run. Let me know if it works.

[rppicomidi]

@doughadfield Rather than do all that, I was asked to submit a pull request to fix the bug in TinyUSB. I am attaching a patch for you to test. If it fixes your issue, I can submit a pull request and fix this for everyone. Please do the following. It assumes that ${PICO_SDK_PATH} points to your pico-sdk directory

cd ${PICO_SDK_PATH}/lib/tinyusb
git checkout master
git pull

Next, extract the attached patch file to your tinyusb directory.

Finally, enter the command

git apply 0001-Fix-3159.patch

Compile and run the midi2usbhost project and see if it enumerates your POD Go. If it works, I will submit a pull request that fixes it for you and everyone else. Thanks for your help.

0001-Fix-3159-patch.zip

[doughadfield]

Thank you so much!! - sorry for the delay in replying... day job got in the way. I'll apply and test your patch today (tuesday) against my two Line6 devices and let you know what happens.

[rppicomidi]

@doughadfield Wonderful. Thank you for working this in between working. To be clear, please test the patch with the current midi2usbhost code, too. I updated it and the midi_uart_lib to allow you to configure the UART buffer size. See the midi_uart_lib_config.h for details. To get the very latest midi2usbhost code,

cd [path to your projects]/midi2usbhost
git pull
git submodule update --recursive

[doughadfield]

Hi again, I created a fresh VSCode project with a new clean clone of mkdk2usbhost. I compiled it against the vanilla (up to date) pico-sdk tinyUSB submodule and tested - same behaviour as before. I then applied your patch, which modified midi_host.c as expected. Heres the output of a git status:

doug.hadfield@doug-vast tinyusb % git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: src/class/midi/midi_host.c

Untracked files:
(use "git add ..." to include in what will be committed)
0001-Fix-3159-patch.zip
0001-Fix-3159.patch

I then re-compiled the midi2usbhost project in VSCode and re-flashed - unfortunately the same behaviour :-(
How can I be sure the tinyUSB library has been re-compiled? the VSCode output window went so fast I couldn't see which individual files were being compiled - it was all over in less than a second, which makes me suspicious (I'm running on an M1-Max processor, so it's a pretty fast machine). I then altered the log line in CMakeLists.txt to uncomment "set(LOG 2)" and recompiled again. This time more files were compiled, but again they went past so quick I couldn't see which (the VSCode output window overwrites the compile lines, so they're not readable in the log output :-(

The pico is now providing the debug output on the serial port, but again no joy with enumerating the POD Go. Debug output below - screen cleared just before plugging in POD Go USB:

Buffer complete
[:5] on EP 81 with 1 bytes: OK
HUB xfer callback
Hub Status Change = 0x02
HUB Get Port Status: addr = 5 port = 1
[0:5] Class Request: A3 00 00 00 01 00 04 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 4 bytes: OK
[0:5] Control data:
0000: 01 01 01 00 |....|
Buffer complete
Transfer complete
[:5] on EP 00 with 0 bytes: OK

HUB Clear Feature: PORT_CONNECTION_CHANGE, addr = 5 port = 1
[0:5] Class Request: 23 01 10 00 01 00 00 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 0 bytes: OK

[0:] USBH Device Attach
HUB Get Port Status: addr = 5 port = 1
[0:5] Class Request: A3 00 00 00 01 00 04 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 4 bytes: OK
[0:5] Control data:
0000: 01 01 00 00 |....|
Buffer complete
Transfer complete
[:5] on EP 00 with 0 bytes: OK

HUB Set Feature: PORT_RESET, addr = 5 port = 1
[0:5] Class Request: 23 03 04 00 01 00 00 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 0 bytes: OK

HUB Get Port Status: addr = 5 port = 1
[0:5] Class Request: A3 00 00 00 01 00 04 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 4 bytes: OK
[0:5] Control data:
0000: 03 01 10 00 |....|
Buffer complete
Transfer complete
[:5] on EP 00 with 0 bytes: OK

HUB Clear Feature: PORT_RESET_CHANGE, addr = 5 port = 1
[0:5] Class Request: 23 01 14 00 01 00 00 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 0 bytes: OK

[0:0] Open EP0 with Size = 8
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00
Transfer complete
[:0] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:0] on EP 80 with 8 bytes: OK
[0:0] Control data:
0000: 12 01 00 02 EF 02 01 40 |.......@|
Buffer complete
Transfer complete
[:0] on EP 00 with 0 bytes: OK

Set Address = 1
[0:0] Set Address: 00 05 01 00 00 00 00 00
Transfer complete
[:0] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:0] on EP 80 with 0 bytes: OK

[0:1] Open EP0 with Size = 64
Get Device Descriptor
[0:1] Get Descriptor: 80 06 00 01 00 00 12 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 18 bytes: OK
[0:1] Control data:
0000: 12 01 00 02 EF 02 01 40 41 0E 4B 42 00 02 01 03 |.......@A.KB....|
0010: 02 01 |..|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 00 03 00 00 02 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 2 bytes: OK
[0:1] Control data:
0000: 04 03 |..|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 00 03 00 00 04 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 4 bytes: OK
[0:1] Control data:
0000: 04 03 09 04 |....|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 01 03 09 04 02 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 2 bytes: OK
[0:1] Control data:
0000: 0E 03 |..|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 01 03 09 04 0E 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 14 bytes: OK
[0:1] Control data:
0000: 0E 03 4C 00 49 00 4E 00 45 00 20 00 36 00 |..L.I.N.E. .6.|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 03 03 09 04 02 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 2 bytes: OK
[0:1] Control data:
0000: 0E 03 |..|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 03 03 09 04 0E 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 14 bytes: OK
[0:1] Control data:
0000: 0E 03 50 00 4F 00 44 00 20 00 47 00 6F 00 |..P.O.D. .G.o.|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 02 03 09 04 02 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 2 bytes: OK
[0:1] Control data:
0000: 16 03 |..|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

[0:1] Get Descriptor: 80 06 02 03 09 04 16 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 22 bytes: OK
[0:1] Control data:
0000: 16 03 20 00 20 00 20 00 33 00 34 00 38 00 36 00 |.. . . .3.4.8.6.|
0010: 36 00 32 00 30 00 |6.2.0.|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

Get Configuration[0] Descriptor (9 bytes)
[0:1] Get Descriptor: 80 06 00 02 00 00 09 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 9 bytes: OK
[0:1] Control data:
0000: 09 02 20 00 01 01 00 C0 00 |.. ......|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

Get Configuration[0] Descriptor
[0:1] Get Descriptor: 80 06 00 02 00 00 20 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 32 bytes: OK
[0:1] Control data:
0000: 09 02 20 00 01 01 00 C0 00 09 04 00 00 02 FF 00 |.. .............|
0010: 00 00 07 05 81 02 40 00 00 07 05 01 02 40 00 00 |......@......@..|
Buffer complete
Transfer complete
[:1] on EP 00 with 0 bytes: OK

Set Configuration = 1
[0:1] Set Configuration: 00 09 01 00 00 00 00 00
Transfer complete
[:1] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:1] on EP 80 with 0 bytes: OK
[1] Aborted transfer on EP 01
[1] Aborted transfer on EP 81
[1] Aborted transfer on EP 02
[1] Aborted transfer on EP 82
[1] Aborted transfer on EP 03
[1] Aborted transfer on EP 83
[1] Aborted transfer on EP 04
[1] Aborted transfer on EP 84
[1] Aborted transfer on EP 05
[1] Aborted transfer on EP 85
[1] Aborted transfer on EP 06
[1] Aborted transfer on EP 86
[1] Aborted transfer on EP 07
[1] Aborted transfer on EP 87
[1] Aborted transfer on EP 08
[1] Aborted transfer on EP 88
[1] Aborted transfer on EP 09
[1] Aborted transfer on EP 89
[1] Aborted transfer on EP 0A
[1] Aborted transfer on EP 8A
[1] Aborted transfer on EP 0B
[1] Aborted transfer on EP 8B
[1] Aborted transfer on EP 0C
[1] Aborted transfer on EP 8C
[1] Aborted transfer on EP 0D
[1] Aborted transfer on EP 8D
[1] Aborted transfer on EP 0E
[1] Aborted transfer on EP 8E
[1] Aborted transfer on EP 0F
[1] Aborted transfer on EP 8F

Device configured
Parsing Configuration descriptor (wTotalLength = 32)
[0:1] Interface 0: class = 255 subclass = 0 protocol = 0 is not supported
[5] Claimed EP 0x81
Queue EP 81 with 1 bytes ...
OK

***************** above is output after plugging in POD Go. below is output when POD Go unplugged **************
Buffer complete
[:5] on EP 81 with 1 bytes: OK
HUB xfer callback
Hub Status Change = 0x02
HUB Get Port Status: addr = 5 port = 1
[0:5] Class Request: A3 00 00 00 01 00 04 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 4 bytes: OK
[0:5] Control data:
0000: 00 01 01 00 |....|
Buffer complete
Transfer complete
[:5] on EP 00 with 0 bytes: OK

HUB Clear Feature: PORT_CONNECTION_CHANGE, addr = 5 port = 1
[0:5] Class Request: 23 01 10 00 01 00 00 00
Transfer complete
[:5] on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
[:5] on EP 80 with 0 bytes: OK

[5] Claimed EP 0x81
Queue EP 81 with 1 bytes ...
OK
[0:5:1] USBH DEVICE REMOVED
[0:5:1] unplugged address = 1

---

Below is the new (patched) midi_host.c for reference:

midi_host.c.zip

[doughadfield]

Just reading your latest message, I'll need to run the patch against your previous midi2usbhost code, so I'll try and downgrade the image and try again, hopefully later this evening.

[rppicomidi]

@doughadfield That trace was instructive. It looks like you are attaching the device through a hub. First, it gets the device and string descriptors. Then it gets the first 32 bytes of the configuration descriptor. However, the device returns a configuration descriptor with only 1 interface, self powered; the descriptor is 32 bytes long (09 02 20 00 01 01 00 C0 00). The descriptor dump you sent at the beginning of this issue is 0x117 (279) bytes long. The interface it gives you is vendor specific with 2 endpoints: 09 04 00 00 02 FF 00 00 00. There is one bulk IN and one bulk OUT; both are 64 bytes long 07 05 81 02 40 00 00 07 05 01 02 40 00 00.

I presume that the descriptor dump you sent was from a modern computer with a high speed USB host. It looks like the POD Go tells full speed USB hosts like this one that it has different capabilities. This makes some sense; the largest bulk transfer you can do with a full speed host is 64 bytes. Maybe they are relying on high speed USB to have enough bandwidth to handle the audio and MIDI interfaces on this device. Perhaps you can reach out to LINE 6 to confirm this and find out what, if anything, you can do with the vendor specific bulk endpoints. Or you can go back to using the Raspberry Pi Zero. But there is no high speed USB host port on a Raspberry Pi Pico.

[doughadfield]

This is really interesting. The linux machine I dumped the descriptor from was in fact the raspberry Pi (I can't remember which pi I dumped from - I had a Pi3, Pi4 and Pi zero all working at some stage). Would it help if I dumped the descriptor from multiple systems; high speed (laptop) and low speed (old pi zero) so you can compare the two?

[doughadfield]

Also, would it help if I removed the hub from the data path, and direct-connected the device to the pico, then send you the traces?