Re: [linux-audio-user] Midi data arrives, but gets stuck in ALSA's buffer
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/o.... 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/o...
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
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/o.... 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/o...
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
participants (1)
-
Jens Gulden