View Full Version : Speeding up raw HID communication

06-12-2013, 03:20 AM
Hi all,
I have a VST plugin and I'm building a custom controller for it using the teensy 2.0. I've managed to configure my controller as a raw HID device and in the plugin I'm able to communicate with it fine. I chose raw HID because I wanted to make connecting to the device as user friendly as possible. The problem I'm having is with latency. It seems that using raw HID,I'm not able to communicate as quickly as I can with midi.

Is there any way to configure the raw HID device to communicate faster? I don't require two way communication if that helps. Is there a different device type that might be more appropriate? Any advice would be much appreciated and thank you in advance for any assistance you can offer.


06-12-2013, 06:10 AM
What platform are your running on?

In OS/X Apple has a kernel thread doing Core MIDI that runs at a higher level than regular processes (and many of the kernel functions).
This will beat a regular process doing HID. You can make MIDI devices quite user friendly by filling out the appropriate strings in the USB descriptor.

06-12-2013, 12:10 PM
My plugin runs on both Windows and OSX. Midi is great but it's not totally plug and play in the way an hid device has the potential to be. Midi in daws always needs to be routed as it's controlled by the host and can't be accessed directly. I thought I had found a way around that, but perhaps not.

06-12-2013, 01:20 PM
HID protocol uses USB's "interrupt" transfer type, which has limited bandwidth.

MIDI and Serial use USB "bulk" transfer, which can use all the available USB bandwidth not consumed by other devices.

HID is meant for sending small messages with fixed latency. If you transmit too much (more than fits into a single packet), you must wait until the next polling interval. The USB descriptors in the Raw HID option request a 1 ms polling interval, which is the fastest USB supports. If you're getting much more than 1 ms latency for single-packet message, then something is wrong. What, I can not tell, unless I have the ability to reproduce the problem.

06-12-2013, 02:06 PM
So you're saying that the latency between my measurements on the pins to receiving the data in my application should be about one millisecond? I need about five or less for good results. Does changing the packet size have much affect? And what's the minimum packet size. I tried one byte, but windows wasn't happy about that and failed to install the driver.

06-14-2013, 08:17 AM
I managed to get my bits in order and it's working great. Performance is on par with MIDI if not better.


06-14-2013, 09:18 AM
Great. Glad it's working well now.

Do you have any insights to share, regarding what was causing the latency troubles... and what someone who might have a similar problem (and finds this thread by searching) might do to fix it?

06-14-2013, 09:28 AM
Well, I changed a few things so I can't be sure. On the teensy side I had been setting the timeout for sending the data to 0 ms (only send if a buffer is immediately available), and I changed that 1ms. There was also a bug in my code logic that might have been exasperating things.

Anyways, its all good now I must say that this configuration is very slick and user friendly.