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

[Jens Gulden]

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
> 
>