# Why USB bulk and not interrupt as transfer method? **URL:** \ **Category:** MIOS programming (C)\ **Tags:** bulk, usb, low-latency, usb-interrupt, usb-transfer\ **Created:** [October 18, 2013, 4:52pm UTC](https://forum.midibox.org/t/why-usb-bulk-and-not-interrupt-as-transfer-method/17883 "2013-10-18T16:52:20Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![phanaton](https://forum.midibox.org/letter_avatar_proxy/v4/letter/p/a87d85/32.png) [@phanaton](https://forum.midibox.org/u/phanaton)\ **Post date:** [October 18, 2013, 4:52pm UTC](https://forum.midibox.org/t/why-usb-bulk-and-not-interrupt-as-transfer-method/17883/1 "2013-10-18T16:52:20Z")
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 ---
**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\ **Post date:** [October 20, 2013, 5:35pm UTC](https://forum.midibox.org/t/why-usb-bulk-and-not-interrupt-as-transfer-method/17883/2 "2013-10-20T17:35:29Z")
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](http://ww2.miditest.earthvegaconnection.com) Latency was ca. 2.7 mS, jitter ca. 0.3 mS   Best Regards, Thorsten. ---
**Author:** ![Lippold\_Haken](https://forum.midibox.org/letter_avatar_proxy/v4/letter/l/8baadc/32.png) [@Lippold\_Haken](https://forum.midibox.org/u/Lippold_Haken)\ **Post date:** [February 20, 2021, 3:22pm UTC](https://forum.midibox.org/t/why-usb-bulk-and-not-interrupt-as-transfer-method/17883/3 "2021-02-20T15:22:21Z")
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   ---
**Author:** ![BillyHoffer](https://forum.midibox.org/user_avatar/forum.midibox.org/billyhoffer/32/678_2.png) [@BillyHoffer](https://forum.midibox.org/u/BillyHoffer)\ **Post date:** [March 19, 2021, 10:40am UTC](https://forum.midibox.org/t/why-usb-bulk-and-not-interrupt-as-transfer-method/17883/4 "2021-03-19T10:40:44Z")
I think this method is the most popular among the people and people just don’t know that there are better ways as the name says: SuperSpeed (USB 3.1 Gen 1) up to 5 Gbps!