Hi,
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.)
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), the second command does actually not get dropped.
Example:
When sending the two commands 0xD1 0x10 and 0x91 0x40 0x40 normally, it would produce: sending packet: [ 0d d1 10 00 09 91 40 40 ] When routing the MIDI output through the MIDI THRU port on the MT-32 to a MIDI port on an ES1371, the captured stream is: d1 10 and no note is played on the MT-32. (The 0x91 command is a note-on.)
After hacking out the zero padding, it looks like this: sending packet: [ 0d d1 10 09 91 40 40 ] The re-captured stream is: d1 10 91 40 40, and a note is properly played.
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)? Limit the outgoing packets to 4 bytes like with the ESI M4U for these devices? Add an option to the snd-usb-audio module to toggle this behaviour? Something else?
Best regards, Willem Jan