midi2usbhost icon indicating copy to clipboard operation
midi2usbhost copied to clipboard

Dropped bytes between USB (Nanokontrol2) and UART

Open doughadfield opened this issue 6 months ago • 4 comments

Hi, I've got the device working with unchanged code, and it recognises my Korg NanoKONTROL2 device on the usb. However, when I request a scene dump from the korg device, I get the following on the serial monitor (UART0):

Pico MIDI Host to MIDI UART Adapter Configured MIDI UART 1 for 31250 baud MIDI Device Index = 0, MIDI device address = 1, 1 IN cables, OUT 1 cables manufacturer: KORG INC. product: nanoKONTROL2 Warning: Dropped 8 bytes sending to UART MIDI Out Warning: Dropped 33 bytes sending to UART MIDI Out Warning: Dropped 34 bytes sending to UART MIDI Out Warning: Dropped 33 bytes sending to UART MIDI Out Warning: Dropped 33 bytes sending to UART MIDI Out Warning: Dropped 33 bytes sending to UART MIDI Out Warning: Dropped 3 bytes sending to UART MIDI Out

Would this be a buffer overrun between the (much faster) USB input stream and the UART output stream? If so, am I able to increase the buffer sizes so as to accomodate large sysex messages like this one?

doughadfield avatar Jul 02 '25 09:07 doughadfield

BTW, I would very much like to assist with this project, to show appreciation for the effort you've put in and your sharing of your work with the community. If you can point me at the points in the code, I can work on adjusting buffer sizes (or whatever is needed) and submit tested changes.

doughadfield avatar Jul 02 '25 09:07 doughadfield

checking the code, the usb midi buffer is set at 64 bytes by the tinyusb lib, for "Full speed" connections, but 512 bytes for "HS" connections. The macros in the midi2usbhost code for tx and rx buffer sizes are unused. Therefore, forcing the buffer sizes to 512 bytes (or some larger number than 64) will probably fix this problem - open to advice as to the cleanest way to do this in the code.

doughadfield avatar Jul 03 '25 16:07 doughadfield

@doughadfield Those USB FIFO buffers are not likely what is causing the issue you are seeing. USB MIDI is considerably faster than UART MIDI, even with the relatively slow USB host driver on the RP2040. The UART byte rate is 3125 bytes per second. The USB byte rate is roughly 64000 bytes per second. If you look at tuh_midi_rx_cb(), you can see that the USB MIDI receive buffer gets drained completely to the MIDI UART transmit buffer. If the MIDI UART transmit buffer gets too full, then it will overflow. The scene dump from the NanoKONTROL2 is a lot of data, relatively speaking, and the MIDI UART probably cannot keep up.

You can try increasing the buffer size of the UART buffers, not the USB Host buffers. I did not make that configurable in midi_uart_lib config file and probably should have. Look for #define MIDI_UART_RING_BUFFER_LENGTH 128. Try making that buffer 512 bytes or 1024 bytes and see how you do. The other thing that may help more is enabling the UART FIFO buffers. I was lazy when I wrote the midi_uart_lib driver. An example UART driver with FIFOs enabled is pico_pico_midi_lib.

However, the problem with making big buffers for the UART is the latency can get pretty bad. In a perfect world, the midi_uart_driver will send about one 3-byte MIDI message per millisecond. Because I didn't implement UART FIFOs, it is less fast than that. Let's say you made the UART buffers 1024 bytes. If you make a lot of simultaneous adjustments with the nanoKONTROL2 faders, the UART may still be transmitting almost 0.4 second after you are done moving them. That may seem like an eternity.

rppicomidi avatar Jul 03 '25 17:07 rppicomidi

Once again, thank you so much for your detailed reply and insights. I'm learning a lot about USB MIDI as well as brushing up on my C. I've written microcontroller MIDI controllers in the past (using PIC) but that was a long time ago, and always with UARTS; never USB so that aspect is new to me. I'll have a look at improving the UART throughput via the FIFOs but I'm not worried about the NanoKONTROL - only the POD Go, so I'll focus on getting that going as a priority. Any improvements I make to the UART code I'll pass back in case you can use it.

doughadfield avatar Jul 03 '25 21:07 doughadfield