Re: Midi data arrives, but gets stuck in ALSA's buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux