8 Oct
2006
8 Oct
'06
8:34 a.m.
On Sunday, 8 October 2006 02:38, Jens Gulden wrote:
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.
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
Pedro Lopez-Cabanillas wrote:
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.
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), 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? 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.