[alsa-devel] proposed MPD16 latency workaround

[Krzysztof Foltman]

On 16/09/10 10:02, Clemens Ladisch wrote:

>> 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.

Yes. Well, it's the case of what's right vs. what's convenient. I think 
the assumption that opening a MIDI port (sequencer or raw) won't cause 
disastrous results (like increased latency of some other port) is a fair 
assumption.

Also, working around the problem in the central place (kernel driver) 
is, in my opinion, more convenient than fixing that otherwise-harmless 
behaviour in many other projects (jackd1, jackd2, a2jmidid, another JACK 
implementation by Torben Hohn that I don't know the name of). Especially 
given the minimal popularity of the MPD16.

> 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.

Well, it _could_ be used for some other USB MIDI devices (the ones using 
bulk mode on input endpoints) to reduce data churn on USB ports when 
devices are physically connected but their MIDI ports are not used. 
Probably isn't worth it though: the power and bandwidth use of the 
unnecessary polling is probably minimal.

The MPD16 code *does* use some things in the generic driver, like most 
of the setup code. The only differences are: 1) I/O quirks (and many 
other devices have those), 2) conditional opening of endpoints 
(potentially reusable). I don't think the impact is very severe, 
comparing with the Roland stuff in the same file, for example.

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

That would be great - if you have time for it. I definitely can take 
care of testing/debugging in that case.

> 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.

To clarify: in this solution, to enable control input, you need to send 
a fake sysex on control output. The device has no functional *data* 
output, as far as I can tell - there's only data input which sends 
events from the pads and the slider.

I thought of using alternatives like a hwdep device, a mixer control or 
an ioctl, but those were frighteningly hard to implement and not really 
much nicer for the user. And the control port talks MIDI (SysEx 
messages) anyway.

That specialized control application doesn't even exist at this point. 
So, a low-effort alternative option to consider would be to completely 
drop the ability to configure the device, as most of the configuration 
can be done from the device anyway (the inconvenient but working "hold 
some button, press some pads" type of interface).

If I had to choose between "enormous latency and automatic 
configuration... maybe some day" and "imperceptible latency, but have to 
set it up manually", I'd definitely choose the latter.

Krzysztof