Jump to content

Why USB bulk and not interrupt as transfer method?


phanaton
 Share

Recommended Posts

Hi,

 

This does not belong directly to the MIOS, but I haven't found a better sub-forum for my question...

 

I'm trying to learn a lot of the low level stuff associated with MIDI right now. Mostly about USB connection. The svn repo is pretty good for it. I learned a lot of it already... I'm thinking about implementing myself(for learning purposes) a MIDI-USB connection with my STM32f4 dev board. I'm planning to use an ULPI PHY for HiSpeed Connction to achieve lowest latencies(8 times lower latency than FS). I think the Interrupt transfer method should be the best fit for it, since it has guaranteed latency.

But now I saw in the svn repo that the MIDI-USB endpoint descriptor uses only bulk as transfer method. 

 

Is this just for the compability issue or is it a wrong idea to use the interrupt transfer method, to achieve lowest latencies?

 

Ah just for record, I'm a pretty fussy drummer regarding latencies, since I hear/feel a small difference between 5ms and 10ms(measured and compared by ear...).

 

 

Best Regards

Philipp

Edited by phanaton
Link to comment
Share on other sites

Hi,
 
the USB MIDI spec only refers to bulk transfers, there is no explanation why this transfer method has been preferred instead of interrupt or isochronous transfers. I can only assume, that interrupt transfers might result into more overhead if large data dumps (such as SysEx) has to be transferred. The USB 2 spec recommends interrupt transfers only for small amount of data.
 
Anyhow, if you don't follow the USB MIDI spec, you would have to implement your own USB MIDI driver, and this seems to be a challenge, otherwise open source drivers (e.g. better than the really bad M$ implementation) would already exist.
 

 

Ah just for record, I'm a pretty fussy drummer regarding latencies, since I hear/feel a small difference between 5ms and 10ms(measured and compared by ear...).

 

I guess you mean that jitter is an issue, and not the latency.

I tested the latency and jitter some time ago under Windows with a special benchmark: http://ww2.miditest.earthvegaconnection.com

Latency was ca. 2.7 mS, jitter ca. 0.3 mS

 

Best Regards, Thorsten.

Link to comment
Share on other sites

  • 7 years later...

On some recent Windows 10 systems, BULK IN ENDPOINT polling (IN/NAK) is at a much increased rate.  Presumably this is good for situations where BULK ENDPOINTS have lots of data to transfer, but it is silly for Midi, since at most 1 Midi message will be transferred per millisecond.  The faster poll rate is approximately every 8 microseconds, over 100 times faster than the max Midi rate.  In my situation I have implemented USB-MIDI with my own "bit-banging" style DMA code on a ADSP21489 SHARC, and just the 8 microsecond polling rate (with no Midi data to send) eats 20% of cpu time (where the previous slower polling rate used by windows eats about 4%).

I changed the BULK IN ENDPOINT to use interrupts configured for 1 ms intervals -- and that works fine on all versions of Mac and Windows thatI have tried.  This way the total Midi processing uses 0.2% of the CPU time, leaving much more time for making music.  [I have heard people say that interrupts are at a lower rate, but in every OS I tried interrupts ran at the configured 1 ms rate - maybe the slow interrupts are a Low Speed USB issue not Full Speed USB -- but USB Midi requires Full Speed anyway since it is part of Audio]

I left Midi's BULK OUT ENDPOINT as it was, since Midi output was not a problem - it was the endless input polling (going at a rate more than 100 times the fastest possible input data rate for Midi) that caused the drain on my CPU resources.

I hope this is useful information for someone, Lippold Haken

 

Edited by Lippold Haken
Link to comment
Share on other sites

  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...