Lippold Haken

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