[alsa-devel] unpadded USB MIDI commands
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
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
participants (2)
-
Clemens Ladisch -
Willem Jan Palenstijn