[PATCH 1/3] ALSA USB MIDI: Fix port starvation

[Clemens Ladisch]

Andreas Steinmetz wrote:
> On Tue, 2020-03-17 at 11:26 +0100, Clemens Ladisch wrote:
>> Why is it necessary to immedately get a complete class-compliant
>> message?
>
> Maybe that's a misunderstanding caused by me using 'message' instead of
> 'event'. We need a complete MIDI event (or up to 3 sysex bytes) to form
> the class compliant 4 byte USB event. That's what the 'repeat' shortcut
> is for. And after one such event is collected to the URB the code
> switches to the next port.

Why is it necessary to get a complete USB event before switching to the
next port?  Why not just process one byte in each loop iteration?

>> The point is that we should not restart with the first port in each
>> packet.
>
> I was thinking about that but in practice I do not know any class
> compliant interface that does have a number of outputs that is not
> equal to 2^n, i.e. 1, 2, 4, 8, 16.
>
> Then wMaxPacketSize is also always a 2^m value (16, 64, 512).
>
> With m>=n+2 (I don't believe that there is any class compliant
> interface for which this is not true)

At least ESI M4U has n=2, m=2.  It's for devices like this that the
driver uses multiple packets.  (I do not know if this (revision of
the) device is still used.)

It's certainly true that using the full packet size and 7 packets is
excessive in most situations.  The driver should _automatically_
reduce these values when it is safe.  (I'm not saying that module
parameters are completely superfluous, but they should never be
necessary if the driver can avoid it.)


I think the lowest-hanging fruit are the hardcoded 0x10, and that
port->active is not a single bitfield; the latter will make
searching for active ports easier.  I'll create patches for this.


Regards,
Clemens