[alsa-devel] proposed MPD16 latency workaround

[Krzysztof Foltman]

  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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpd16-control-port.diff
Type: text/x-diff
Size: 6729 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20100916/18203820/attachment.bin