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

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
>
>
Received on Sun Oct 8 08:15:02 2006