[Musix-users] Re: [linux-audio-user] Midi data arrives, but gets stuck in ALSA's buffer

[Jens Gulden]

Hello,

Pedro Lopez-Cabanillas wrote:
 > Most Midisport NxN devices need a firmware

I do know. The device successfully runs on a manually installed debian-system on another computer. I 
originally used the firmware copied from there. Now I tried the firmware you recommended from 
http://linux-hotplug.cvs.sourceforge.net/linux-hotplug/firmware/ezusb/midi/original/ezusbmidi2x2.ihx?view=log. 
It's noticeably a different one than the one I used before (because input-leds flash shorter and no 
longer flash on midi-active pings), but...

...still the same problem. :-(

I even bought an Edirol UM-1EX today, which does not need a firmware-download and is listed to work 
properly on http://qbik.ch/usb/devices/search_res.php?pattern=midi ('EX' shouldn't be too different 
from 'SX', I guess), but...

...exactly the same behaviour. :-(
The device is correctly recognized and shows up in qjackctl's midi-tab, but connecting it to 
timidity, or connecting from vkeybd, does not have an effect, except that one can watch the "Avail" 
numbers increase in /proc/asound/cardX/midi0. Also tested with Musix 0.59 and 0.49, also on a 
different computer.

--> Is anybody reading this successfully using a USB-MIDI interface on a Musix system? Please 
quickly drop a note! <--

 > I can confirm your findings with ALSA 1.0.12
 > I've verified also the RPM distributed by Planet CCRMA, and it is OK.

So, you actually reconstructed the problem with a MidiSport 2x2 device, and then successfully solved 
it with that firmware? Did you?

 > It is *not* a bug in ALSA.

Mmmh, according to my experience with the UM-1EX behaving exactly the same, it still does looks like 
an ALSA problem, at least with the way it is deployed on Musix...

 > Seems that Musix has distributed corrupted firmware files. Please don't use them.

I haven't even found them in the Musix distribution... /etc/hotplug/usb/ezusbmidi references 
/usr/share/usb/ezusbmidi/ezusbmidi2x2.ihx, but that one doesn't exist. I solved this using Knoppix's 
configuration mechanism, saving files in /etc in a config.tbz on a memory stick, together with 
ezusbmidi2x2.ihx, modifying /etc/hotplug/usb/ezusbmidi to point to that ezusbmidi2x2.ihx, and start 
Musix with "myconf=/dev/sda1" at the boot prompt. This works with Musix 0.50, but seems to be 
disabled in 0.59.
Anyway, the problem seems to have nothing to do with firmware as it occurs with the other device, too.

 > the ALSA /proc interface reported that incoming data was received, but the data wasn't good.

Where can I find out if the data is considered to be "not good"? Which file under /proc says that?

best
Jens


Pedro Lopez-Cabanillas schrieb:
> On Friday, 6 October 2006 22:33, Jens Gulden wrote:
> 
>>Hello, very weird:
>>
>>cat /proc/asound/card2/midi0 ->
>>
>>MidiSport 2x2
>>
>>Output 0
>>   Tx bytes     : 0
>>Output 1
>>   Tx bytes     : 0
>>Input 0
>>   Rx bytes     : 1186
>>   Buffer size  : 4096
>>   Avail        : 1186  <--- ### SHOULD BE 0, NOT ==RX BYTES! ###
>>   Overruns     : 0
>>Input 1
>>   Rx bytes     : 0
>>
>>Instead of passing the data further to the connected timidity, it gets
>>stuck in the receive-buffer. When 4096 is reached, overruns start to count
>>up.
>>
>>Connections have been set up using qjackctl. vkeybd->timidity works fine.
>>
>>The system is Musix0.50b12, realtime-kernel 2.6.15.4, with manually added
>>MidiSport2x2 firmware. However, I don't think this is a typical
>>"My-MidiSport-does-not-run-on-Musix" problem, as the firmware successfully
>>loads and the MidiSport gets recognized as available device in ALSA. Even
>>the data seems to arrive well as shown by "Rx bytes" (number of bytes per
>>note-event is correct). What is wrong?
> 
> 
> Short answer: the firmware distributed with Musix. It looked like a problem 
> with the drivers, because the ALSA /proc interface reported that incoming  
> data was received, but the data wasn't good.
> 
> Most Midisport NxN devices need a firmware, that must be loaded in the device 
> on each power on, before using it. For devices where N <= 2, there is a free 
> (libre) firmware, GPL licensed, that can be used instead the propietary one. 
> The GPL firmware, written in C by Lars Doelle, can be compiled with the SDCC  
> compiler, and it is standards compliant (using it, the Midisport behaves as 
> described by the USB MIDI specification document).
> 
> Seems that Musix has distributed corrupted firmware files. Please don't use 
> them. 
> 
> You can use the propietary firmware made by M-Audio (Midiman). It works well, 
> although not standard (and no sources are available). You can find it here: 
> http://sourceforge.net/projects/usb-midi-fw
> 
> CVS repository where you can find correct GPL firmware sources, and ready to 
> use .ihx images:
> http://linux-hotplug.cvs.sourceforge.net/linux-hotplug/firmware/ezusb/midi/original/
> 
> The tarball distributed by NAGANO Daisuke with the OSS-like driver also 
> contains the correct firmwares:
> http://homepage3.nifty.com/StudioBreeze/software/usbmidi-e.html
> 
> I've verified also the RPM distributed by Planet CCRMA, and it is OK.
> 
> Size and MD5 hash for correct firmwares:
> 
> $ ls -l *.ihx
> -rw-r--r--  1 pedro pedro  7620 Oct  7 20:19 ezusbmidi1x1.ihx
> -rw-r--r--  1 pedro pedro 10168 Oct  7 20:19 ezusbmidi2x2.ihx
> 
> $ md5sum *.ihx
> 4d78294c5fd4575cf52a297e5f2f1e53  ezusbmidi1x1.ihx
> 23427b43a718feea911970746af174e7  ezusbmidi2x2.ihx
> 
> Regards,
> Pedro