Re: proposed MPD16 latency workaround

[Clemens Ladisch <clemens@ladisch.de>]

Krzysztof Foltman wrote:
> 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.

This can be considered a bug in those programs.

> 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

I also have doubts, but I didn't look too much into this.

Since this device uses a completely vendor-dependent protocol, your
changes result in a driver that uses practically none of the common
code for the MPD16.  Furthermore, your code makes it harder to maintain
the driver because these parts of the code cannot be tested without the
MPD16.  In other words, I think that writing a separate driver would be
a better idea.

I'll see if I can write it until Monday; you'll just have to test it
and remove my bugs.  :)

> and about the elegance of the SysEx approach (vs. ioctl or something
> else).

If the control port is used only by some specialized control
application, it doesn't matter too much which mechanism is used.
If the data port is already being used by it, the SysEx approach
would indeed be the simplest to use.


Regards,
Clemens