Aha, usb-midi seems to work with Musix's _non_-realtime kernel at least.
This is not a perfect solution for me as the non-realtime kernel doesn't boot on the machine I would
like to run it on, but at least I can do some tests on another one.
I'll file a bug-report to Musix when I have time again. Thanks so far, Pedro.
Jens
Jens Gulden wrote:
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
