On Sunday, 8 October 2006 02:38, Jens Gulden wrote: > 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), The input leds behavior is different in the proprietary firmware. The GPL firmware don't activate the leds on ActiveSensing MIDI events (see the lines ezusbmidi.c:237 and 254). If you saw the input leds blinking when the device is receiving only ActiveSensing events, then you were using the MAudio proprietary firmware. If you prefer the proprietary firmware behavior, you only need to change the mentioned lines, to something like this: ezusbmidi.c:237 - if (dta!=0xfe) ledIN ^= 1; // ignore active-sensing + ledIN ^= 1; ezusbmidi.c:254 - if (dta!=0xfe) ledIN1 ^= 1; // ignore active-sensing + ledIN1 ^= 1; It is also possible to ignore completely the ActiveSensing events, if you wish so. It is free (libre) software, so you can change it to fit your needs. The main difference, though, between the proprietary and the GPL firmware is the standards compliance, that you can see using the command "lsusb -v" with the device when using each one. > > 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? Well, not exactly. I was testing a broken firmware that didn't receive any MIDI data, although it was sending MIDI correctly. This broken firmware wasn't distributed by Musix. It was an old deprecated copy I had in my system. I though at first that both scenarios were related, but seems that you have found a very different problem. > > 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. Agreed. And about the firmware package distributed by Musix, you are right. ftp://musix.ourproject.org/pub/musix/deb/ez-usb-firmwares_0.1-1_i386.deb The package is located at the above URL is missing the firmware files. It only contains documents, as you can confirm using the dpkg --contents command as shown below. The firmware files have a file name matching the pattern '*.ihx' $ dpkg --contents ez-usb-firmwares_0.1-1_i386.deb drwxr-xr-x root/root 0 2006-06-25 03:26:54 ./ drwxr-xr-x root/root 0 2006-06-25 03:22:53 ./etc/ drwxr-xr-x root/root 0 2006-06-25 03:22:53 ./etc/hotplug/ drwxr-xr-x root/root 0 2006-06-25 03:22:53 ./etc/hotplug/usb/ -rwxr-xr-x root/root 934 2006-06-25 03:22:52 ./etc/hotplug/usb/ezusbmidi -rw-r--r-- root/root 885 2006-06-25 03:22:52 ./etc/hotplug/usb/ezusbmidi.usermap drwxr-xr-x root/root 0 2006-06-25 03:22:53 ./usr/ drwxr-xr-x root/root 0 2006-06-25 03:22:53 ./usr/share/ drwxr-xr-x root/root 0 2006-06-25 03:22:53 ./usr/share/doc/ drwxr-xr-x root/root 0 2006-06-25 03:22:53 ./usr/share/doc/firmwarehotplug-0.1/ -rw-r--r-- root/root 438 2003-05-02 19:17:10 ./usr/share/doc/firmwarehotplug-0.1/README Regards, Pedro
