[alsa-devel] need help diagnosing USB MIDI latency problem with MPD16

[Krzysztof Foltman]

  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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xboard.usb
Url: http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20100915/d89f1c89/attachment.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: akai.usb
Url: http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20100915/d89f1c89/attachment-0001.bat 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: akai.py
Type: text/x-python
Size: 1907 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20100915/d89f1c89/attachment.py