Re: unpadded USB MIDI commands

[Clemens Ladisch <clemens@ladisch.de>]

Willem Jan Palenstijn wrote:
> I recently investigated some trouble with sending MIDI via a USB MIDI cable
> (15ca:1806) to a Roland MT-32. In some cases, commands were being dropped.
> 
> (This is what is reported on
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3752 . I'm the colleague
> mentioned by druon in note 0021737 there.)

Apparently, the bug tracker drops some email notifications.

> After we experimented a bit, it turned out that packets of 2 MIDI commands (8
> bytes total) were being sent to the USB MIDI cable, and that if the first of
> these was a 2-byte MIDI command (such as a 0xC0 or 0xD0 command), the second
> command in the packet would get dropped.
> 
> A workaround is to limit the packet size to 4 bytes, as is already happening on
> at least one other device (the ESI M4U referred to in usbmidi.c).
> 
> I played with it some more this week, and it turns out that if the zero-padding
> from the USB MIDI commands is removed (violating the specs, as far as I
> understand),

Indeed.

> the second command does actually not get dropped.

I'd guess a certain other OS never sends more than 4 bytes in one packet.

> What do you think would be the right way to handle this problem? Don't zero-pad
> the outgoing packets for this specific device (and maybe a few others mentioned
> on bug #3752, if they end up suffering from the same bug)?

This would be possible, but there is no existing driver that actually
uses such a protocol, so I wouldn't want to rely on some implementation
detail that is likely to be changed in some other firmware revision.

> Limit the outgoing packets to 4 bytes like with the ESI M4U for these
> devices?

This is what the device expects.  The driver can have multiple active
packets, so this shouldn't reduce MIDI bandwidth.

> Add an option to the snd-usb-audio module to toggle this behaviour?

This might be useful if other such devices are found.  Or we could use
a whitelist of vendors whose devices work correctly.


Regards,
Clemens