USB MIDI Interface

[winelight]

Hi everyone

Thanks to everyone who's worked on V-USB and V-USB-MIDI and had posted great tips in this thread and other places. My MIDI project is now working, however, like everyone else I would love it to go faster!

One thing I cannot seem to find an answer on is:

How many MIDI Event Packets can you send in one go?

I've seen:

Most (nearly all) examples only sending one packet

A very few examples (and a couple of comments) suggesting two (for a total of 8 bytes) is OK

Suggestions that you can have multiple packets - although this may only apply to bulk transfers.

Does anyone have a definitive answer please?

(edit) Well I've found by experimentation that if I return two packets, it's fine, but more than that, something somewhere goes wrong.

So I guess I have my answer, but I'd like to know where it's documented please!

[horo]

How many MIDI Event Packets can you send in one go?
...
So I guess I have my answer, but I'd like to know where it's documented please!

Hi winelight,

You're right, two packets with a total of eight bytes is the maximum.
USB MIDI transfers are defined as bulk transfers which are not allowed for low speed devices - but it's possible to change them into interrupt transfers in the device descriptor (see my post above http://forums.obdev.at/viewtopic.php?f=8&t=1352&start=15#p9104).

I've found a very good documentation (USB in a NutShell) which states about package size:

Interrupt Transfers
The maximum data payload size for low-speed devices is 8 bytes.

I've printed the NutShell docs along with the official USB MIDI docs and used them while I developed the VUSB MIDI interface. These papers are now quite crinkled and bear notes in different colors - but hey - the software works.

Ciao, Martin

[winelight]

Hi thanks for that. Nice to have it confirmed that I wasn't doing something wrong!

I have my project all working now but the latency is too high. I'm using Windows 7 and know it would be better with Linux and its 2mS poll time, but to be honest I will probably go to a USB hardware solution like the Teensy in the end.

[Guest]

hello,

how do usb midi work with windows 8?

thx georgiu

[Guest]

I've used this library to build a little CV/Gate interface and it's working great on OS X (>= 10.6.3+ when they removed the "sanity check" on the poll interval), iOS and Linux, but on windows we are limited by the 8ms poll time. I am wondering if someone has successfully tried to patch system drivers to overcome this limitation - looks like it's a common practice among gamers who want to increase the poll rate of their mice.

[winelight]

Unfortunately that patch only helps mice, I eventually discovered. This is a real problem on Windows and really the only option is to use something else in most cases. Windows XP has a higher polling speed, but the application I run needs a minimum of Windows 7 and ideally Windows 7 64-bit.

[Fabian]

Hi,

any improvements of the 8ms problem on windows? I saw tests some pages above with linux, but how is windows performing?

Thank you
Fabian

[winelight]

There is nothing that can be done on Windows 7. I don't know about Windows 8.

[Eye]

I've found a solution for the latency (slow interrupt transfer) problem in Windows 7 32-bit.
You have to patch usbport.sys file. USBPORT_OpenEndpoint() function in the USB port driver limits polling period to 8-32 range. Here is the lower limit checking code:

Code: Select all

00009e18: 3c08            cmp al, 8                    // compare with 8
00009e1a: 7309            jnc loc_00009e25             // skip if greater than or equal to 8
00009e1c: c6831a01000008  mov byte ptr [ebx+11ah], 8   // set interval to 8

So, for example, to change the limit to 1, search for the sequence:
3C 08 73 09 C6 83 1A 01 00 00 08
and change to:
3C 01 73 09 C6 83 1A 01 00 00 01

Tested with usbport.sys 6.1.7601.18251 and .18328 (offset for the sequence = 00009e18).

Warning: Windows 7 allows only signed drivers to be loaded, so you have to sign modified usbport.sys before replacing the original file.
1. copy C:\Windows\System32\drivers\usbport.sys to some folder
2. patch the copy of the file with a hex editor
3. run Driver Signature Enforcement Overrider (DSEO) and enable test mode
4. run DSEO again and sign the patched file (check if the file has changed its size after signing)
5. replace the original usbport.sys with the signed copy (use Se7en File Replacer)


Don't forget to change bInterval values in your project's Interrupt IN/OUT Endpoint Descriptors. bInterval=1 seems to work fine - tested with long sysex dumps.

[winelight]

Thanks for that - looks great. I imagine it must be similar on Vista; will do some work on that when I get a chance.

(edit) On Vista the location is different (on mine it was 01f824) and the byte sequence is slightly different too:

3C 08 73 09 C6 86 1E 01 00 00 08

Note the two 08s are in the same relative position.

[jasmin]

Ok, there's a solution for Vista and W10, what's about W10?

jasmin

[winelight]

I am guessing (it is only a guess) that it will be similar to 7 and Vista; but at a different location and with a slightly different byte sequence. Next week I may have time to take a look if that will help (and if I remember!).

[winelight]

OK I did remember eventually. But in usbport.sys in W10 I can't find any of the relevant byte sequences.

So I did some research and it appears that Microsoft has removed the poll rate limitation in Windows 10.

[jokkebk]

Hi all!

Thanks to Martin for the great V-USB MIDI efforts. I combined Adafruit Trinket USB HID keyboard code and MIDI project to arrive at Adafruit Trinket & Pro Trinket MIDI library:

https://github.com/jokkebk/TrinketMIDI

Unfortunately, my ultimate goal wiring the Pro Trinket hardware UART RX line to a old school MIDI connector (via optoisolator of course) has failed. It may be bugs in my code, but because ATmega328's "data overrun" flag in USART registers is getting set, I'm suspecting V-USB communication under OS X is taxing the MCU too much to receive 31 250 baud UART transmissions (there's only 2 byte FIFO in the thing, Trinket ATtiny85 did not even have HW UART so that was useless).

Does someone know how long V-USB interrupts, usbPoll and sending the MIDI packet takes? Based on quick calculation, two bytes of 8N1 MIDI data take 640 us. Is there a way to measure V-USB processor usage? Oscilloscope? Timing usbPoll()? Timing usbSetInterrupt()? It would be helpful if there was documentation how different parts of V-USB work together to even puzzle out which methods take up the most time...

[Coda]

@jokkebk - no the USB does not cause an issue with 31250 baud serial comms, I have successfuly programmed a MIDI-USB cable using a tiny4313 which can handle large streams of sysex in both directions. It sounds like you are getting an overrun because you are not doing any flow-control. You need to make a buffer of at least 16 bytes in ram (I used 32), so that the receive routine has got somewhere to store incoming bytes for the USB routine. Then you need to make sure you are servicing USB requests every 1 millisecond (check the binterval, as written above by 'Eye').