]> git.karo-electronics.de Git - karo-tx-linux.git/commit
ALSA: usb-audio: work around CH345 input SysEx corruption
authorClemens Ladisch <clemens@ladisch.de>
Sun, 15 Nov 2015 21:39:08 +0000 (22:39 +0100)
committerTakashi Iwai <tiwai@suse.de>
Mon, 16 Nov 2015 07:59:29 +0000 (08:59 +0100)
commita91e627e3f0ed820b11d86cdc04df38f65f33a70
tree5c37641e048d18b480c2fcaf03136f2ca455317c
parent1ca8b201309d842642f221db7f02f71c0af5be2d
ALSA: usb-audio: work around CH345 input SysEx corruption

One of the many faults of the QinHeng CH345 USB MIDI interface chip is
that it does not handle received SysEx messages correctly -- every second
event packet has a wrong code index number, which is the one from the last
seen message, instead of 4.  For example, the two messages "FE F0 01 02 03
04 05 06 07 08 09 0A 0B 0C 0D 0E F7" result in the following event
packets:

correct:       CH345:
0F FE 00 00    0F FE 00 00
04 F0 01 02    04 F0 01 02
04 03 04 05    0F 03 04 05
04 06 07 08    04 06 07 08
04 09 0A 0B    0F 09 0A 0B
04 0C 0D 0E    04 0C 0D 0E
05 F7 00 00    05 F7 00 00

A class-compliant driver must interpret an event packet with CIN 15 as
having a single data byte, so the other two bytes would be ignored.  The
message received by the host would then be missing two bytes out of six;
in this example, "F0 01 02 03 06 07 08 09 0C 0D 0E F7".

These corrupted SysEx event packages contain only data bytes, while the
CH345 uses event packets with a correct CIN value only for messages with
a status byte, so it is possible to distinguish between these two cases by
checking for the presence of this status byte.

(Other bugs in the CH345's input handling, such as the corruption resulting
from running status, cannot be worked around.)

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/usb/midi.c