Is Teensy USB MIDI slow?

yeahtuna

Well-known member
I have some someone telling me that the another class compliant USB MIDI device (Roland drum module) can deliver MIDI to the operating system 2ms faster than a Teensy 3.2. Does that sound plausible? If there is way to get faster MIDI performance out of a Teensy, than I'm all ears, but I'm finding it hard to the believe that a Teensy 3.2 is holding on to MIDI events for 2ms. And yes, I'm using send_now().
 
I have some someone telling me that the another class compliant USB MIDI device (Roland drum module) can deliver MIDI to the operating system 2ms faster than a Teensy 3.2. Does that sound plausible?

Only plausible if not using send_now().


but I'm finding it hard to the believe that a Teensy 3.2 is holding on to MIDI events for 2ms. And yes, I'm using send_now().

Everything on the Teensy side software should happen in just a few microseconds. When you call send_now(), Teensy definitely isn't "holding on" to your MIDI messages. It's written into a USB packet buffer and given to the USB device hardware to transmit.

As with all USB communication, the USB host is fully in control of when data is actually transferred. The USB packet with your MIDI message(s) is transferred the next moment your PC's USB host controller sends an IN token.

Then it's just a matter of how long the time is from the moment send_now() finalized the USB packet to when the IN token arrives from your PC, allowing the USB device hardware in Teensy to transmit the packet with your MIDI message(s). Many host controllers have a low power feature where they wait a short time if all non-periodic endpoints have responded with NAK or NYET tokens and it is not yet time to send SOF or query the periodic endpoints. The lists of endpoints/pipes are stored in your PC's RAM. If no actual communication is possible, you don't want the host controller "thrashing" your PC's memory at maximum possible speed. How long the host controller chip waits isn't a required spec, but I seem to recall seeing a 50us guideline in the EHCI 1.0 spec. Host controllers for laptops might have extra low power features, where they could trade latency for lower memory bandwidth. The point is you could suffer a delay about that long, from the moment the USB packet is ready to transmit on the Teensy side until your PC's host controller actually sends the IN token which lets Teensy's USB device controller reply with the data.

The PC host controller automatically puts the device's data response into memory using DMA. But driver software is usually not immediately notified. Most host controllers have a feature where interrupts are delayed and grouped into a batch every 1ms frame or a multiple of 125us micro-frame. This adds latency, but interrupts have a lot of overhead on modern PC operating systems, so this feature is meant to throttle the rate of interrupts for more efficient CPU use, but it come with a small latency cost. Then of course there is interrupt latency before the host controller driver runs, and even more latency from the drivers doing their work to actually scheduling the user level program to execute and read the incoming messages the driver received. This can be on the scale of 1 to 16ms, if using Microsoft Windows.
 
Thanks for the detailed response, Paul. And I assume there's no difference between a Teensy 3.x and Teensy 4 in this regard?
 
Teensy 3.x only supports 12 Mbit USB device. Teensy 4.x supports 480 Mbit, but can also run at 12 Mbit, but that is very rare in these modern times. It's been about 20 years since PCs and USB hubs with only 12 Mbit speed were on the market.

480 Mbit should be much faster. It's not just bandwidth. The USB controller working in 125 micro frames rather than 1 ms frames makes a difference, though again, how long the interrupt latency is configured is a detail generally outside of your control when using Windows or MacOS (and on Linux, might require pretty deep kernel tweeking or hacking).

But Teensy 4's USB stack isn't nearly as mature. I do have this issue on my list of stuff to investigate "soon" (realistically, at least weeks away, maybe months)

https://forum.pjrc.com/threads/6580...chrome-s-new-USB-function?p=266317#post266317

The USB Serial and MIDI code use a different approach to flushing partial packets. USB Serial tries to wait longer. USB MIDI turns on the SOF interrupt, so if you don't call send_now(), the Teensy-side latency should be at most 125us when running at 480 Mbit speed.
 
Back
Top