On Mon, 2007-08-06 at 12:41 +0200, Clemens Ladisch wrote:

Damon Chaplin wrote:

...

I have a CME UF5 MIDI keyboard (USB), which mostly works fine with ALSA.

However if I move the Master Volume slider I stop getting MIDI events - I have to disconnect the snd_seq port and reconnect it to get MIDI events working again.

Is there any error message in the system log when this happens?

No, I don't think so. You mean /var/log/messages?

...

Also, I wanted to try the rawmidi test app, but what would the device ID be?

Have a look at the output of "amidi -l".

Thanks. I've got rawmidi working, and it doesn't seem to have a problem with the master volume slider. So I guess it is an alsa-seq issue.

If I move the slider I get this in rawmidi (4 lines for each increment):

read f0 read 01 read 7f read 7e

read f0 read 01 read 7f read 7d

Are they valid MIDI messages?

Damon

On Wed, 2007-08-08 at 10:11 +0200, Clemens Ladisch wrote:

Damon Chaplin wrote:

...

If I move the slider I get this in rawmidi (4 lines for each increment):

read f0 read 01 read 7f read 7e

read f0 read 01 read 7f read 7d

Are they valid MIDI messages?

No. These look like the first four bytes of master volume sysex messages, but anything after the first four bytes seems to be missing. Sysex messages end with a F7 byte, so it's possible that the following data gets misinterpreted.

Please show the output of "amidi --dump" with some key presses after you've used the master volume slider.

Here's a few key presses, then some master volume slider movement, then another few keypresses:

90 2B 4A 80 2B 24 90 30 34 80 30 27 90 34 3A 80 34 3A F0 01 7F 7D F0 01 7F 7C F0 01 7F 7B F0 01 7F 7A F0 01 7F 79 F0 01 7F 78 F0 01 7F 77 F0 01 7F 76 90 2D 29 80 2D 1D 90 30 29 80 30 24 90 34 49 80 34 34

Damon

(By the way another UF5 user has noticed the same problem, so it isn't just my system. And I'm using Fedora 6, which has alsa-lib-1.0.12-2.fc6)

On Wed, 2007-08-08 at 16:44 +0200, Clemens Ladisch wrote:

Damon Chaplin wrote:

...

On Wed, 2007-08-08 at 10:11 +0200, Clemens Ladisch wrote:

...

Please show the output of "amidi --dump" with some key presses after you've used the master volume slider.

Here's a few key presses, then some master volume slider movement, then another few keypresses:

90 2B 4A 80 2B 24 90 30 34 80 30 27 90 34 3A 80 34 3A F0 01 7F 7D F0 01 7F 7C F0 01 7F 7B F0 01 7F 7A F0 01 7F 79 F0 01 7F 78 F0 01 7F 77 F0 01 7F 76 90 2D 29 80 2D 1D 90 30 29 80 30 24 90 34 49 80 34 34

All keypresses arrive correctly.

Looks like a bug in the keyboard's firmware.

Yes, I wouldn't be completely surprised. They did seem to have some driver issues on Windows.

Please check whether the later keypresses arrive when using aseqdump.

This is a few keypresses, then some slider movement, and more keypresses. It looks like it's got completely confused by the input:

Waiting for data. Press Ctrl+C to end. Source_ Event_________________ Ch _Data__ 20:1 Note on 0 41 42 20:1 Note off 0 41 18 20:1 Note on 0 45 58 20:1 Note off 0 45 20 20:1 Note on 0 48 58 20:1 Note off 0 48 33 20:1 Note on 0 43 65 20:1 Note off 0 43 32 20:1 System exclusive F0 01 7F 39 F0 01 7F 3C F0 01 7F 3D F0 01 7F 3E F0 01 7F 41 F0 01 7F 43 F0 01 7F 46 F0 01 7F 49 F0 01 7F 4D F0 01 7F 51 F0 01 7F 54 F0 01 7F 58 F0 01 7F 5C F0 01 7F 5F F0 01 7F 64 F0 01 7F 67 F0 01 7F 6B F0 01 7F 6E F0 01 7F 71 F0 01 7F 72 F0 01 7F 73 F0 01 7F 74 F0 01 7F 70 F0 01 7F 6B F0 01 7F 64 F0 01 7F 5E F0 01 7F 57 F0 01 7F 4F F0 01 7F 47 F0 01 7F 40 F0 01 7F 3F F0 01 7F 45 F0 01 7F 4B F0 01 7F 50 F0 01 7F 54 F0 01 7F 5A F0 01 7F 5E F0 01 7F 60 F0 01 7F 5A F0 01 7F 52 F0 01 7F 49 F0 01 7F 40 F0 01 7F 3C F0 01 7F 32 F0 01 7F 29 F0 01 7F 23 F0 01 7F 20 F0 01 7F 26 F0 01 7F 2E F0 01 7F 36 F0 01 7F 3D F0 01 7F 41 F0 01 7F 49 F0 01 7F 4F F0 01 7F 53 F0 01 7F 50 F0 01 7F 48 F0 01 7F 3F F0 01 7F 3A F0 01 7F 2E F0 01 7F 23 F0 01 7F 1C F0 01 7F 17 F0 01 7F 19 20:1 System exclusive F0 01 7F 20 F0 01 7F 29 F0 01 7F 33 F0 01 7F 3C F0 01 7F 3E F0 01 7F 45 F0 01 7F 48 F0 01 7F 49 90 2F 1C 80 2F 1C 90 2F 40 80 2F 29 90 32 2F 90 30 29 80 30 0C 80 32 24 90 32 4D 80 32 29 90 32 4A 80 32 2A 90 32 3D 80 32 32 90 32 41 80 32 37 90 32 47 80 32 36 90 32 49 80 32 27 90 2D 35 90 35 38 80 2D 0B 90 34 26 80 35 0C 90 2D 06 80 34 0B 90 35 4D 80 2D 11 90 34 36 90 32 3C 90 2D 44 80 35 0F 80 34 1F 80 32 0A 90 35 4A 80 2D 1A 90 34 41 90 32 26 80 35 1D 90 2D 46 80 34 1A 80 32 0E 90 35 54 80 2D 17 90 34 31 90 32 3C 80 35 1C 90 2D 3C 80 34 13 80 32 17 80 2D 15 90 35 43 90 34 49 90 32 44 80 35 1C 90 2D 47 80 34 19 80 32 1E 90 35 36 80 2D 1D 90 34 3D 90 32 4D 80 35 1C 90 2D 49 80 34 16 80 32 1F 80 2D 1A 90 34 54 90 35 0A 90 32 4A 80 35 14 90 2D 47 80 34 27 80 32

Is it possible to workaround the problem?

Damon

I wrote:

Damon Chaplin wrote:

...

Is it possible to workaround the problem?

Only by changing the driver. Please wait until tomorrow.

Well, the driver should now continue after receiving bad data.

To be able to convert the data sent by the CME UFx to a real master volume message, I need to know the data format at a lower level. Please change line 58 of sound/usb/usbmidi.c to #define DUMP_PACKETS and recompile the driver, then show the entries that are written to the (debug) system log when a master volume message is received.

Regards, Clemens