Hi all,
I've played with USB MIDI driver and MPD16 a bit more. The problem is definitely triggered by submitting URBs on the configuration input endpoint - when these are killed, the latency disappears. Disabling the configuration port works, but is a bit heavy-handed, so I've implemented a workaround: initially, the URBs for the input configuration endpoint are not submitted until two conditions are met:
i) the control port is actually open (I check that using input_triggered bitmask)
ii) the driver is switched into config mode by sending a special SysEx message to the output port (which is intercepted by the driver and used to set a flag). This is to prevent programs that open all the MIDI ports in the system (JACK daemon with ALSA MIDI driver, a2jmidid etc.) from starting unwanted communication with configuration endpoints.
Any time one of these conditions is changed, the driver may either submit the URBs or kill them or do nothing - depending on the difference between expected and current "queuing state" of the URBs. This logic is only used for MPD16, for all the other devices the driver always submit their input URBs, no matter if any input is actually wanted or not.
The attached diff is relative to the Ubuntu 2.6.35 kernel, but I'm mostly interested in the review of the general approach - I have some doubts about thread-safety of calling snd_usbmidi_input_update_ep from send function and about the elegance of the SysEx approach (vs. ioctl or something else). If the approach is not too icky and doesn't have hidden flaws, I can try to create a diff relative to alsa-kernel or some other tree.
Any comments? Krzysztof