Hello,
Some time ago, I wrote the Akai MPD16 protocol handlers (input/output) for the USB MIDI driver. Unfortunately, the kernel driver seems to suffer from a rather embarrassing input latency, it looks like the MIDI event timing granularity is >100ms (so the latency is variable, making the pad practically useless except if a rhythm is played with the rate matching the polling rate!). At the same time, a simple Python based contraption using libusb and bulkRead in a while loop, gets much better results. The same USB MIDI driver in the same kernel and PC doesn't have noticeable problems with class-compliant E-Mu Xboard25 connected to the same USB port.
Both devices use endpoints in bulk mode. I've attached the excerpts of lsusb -v output for both devices - the only differences are:
1) the Akai device isn't class compliant, 2) the E-mu device has one pair of inputs/outputs, the Akai has two (control/configuration and MIDI proper) 3) the maximum packet length is 32 for E-mu, 64 for Akai.
When I enabled logging in midi.c (#define DUMP_PACKETS), it looks like the device is returning data packets rather infrequently, as a single packet often contains multiple events (up to 3) when two pads are pressed in rapid succession. So, it looks like a problem outside of my snd_usbmidi_akai_input.
One thing that *does* help, though, is disabling the 'control' port by adding endpoints[0].in_cables = 0; in Akai quirk handling in snd_usbmidi_create - when input from the control port is not polled, the choppiness disappears completely. I'm guessing that the device itself (or something in between) has some problems having to handle the URBs for both endpoints, and that perhaps the IN/NAK exchange on a "control" endpoint causes the device's microcontroller (or something else?) to stall for a while. However, in that case, a proper solution (one that doesn't involve sacrificing the ability to use control port for configuration) would involve submitting URBs for the control input endpoint only when control port is open on ALSA side, and cancelling them when the port is closed. However, that sounds pretty invasive.
Any hints? The device in question is rather uncommon and hasn't been supported for a while, so refactoring the whole USB MIDI driver to accommodate it doesn't sound like a great idea - but still, the latency thing sucks pretty bad for a drumming-oriented device!
Thanks in advance, Krzysztof