[linux-audio-user] Midi data arrives,
but gets stuck in ALSA's buffer
pedro.lopez.cabanillas at gmail.com
Sun Oct 8 06:34:20 EDT 2006
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
>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:
- if (dta!=0xfe) ledIN ^= 1; // ignore active-sensing
+ ledIN ^= 1;
- 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.
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
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
-rw-r--r-- root/root 438 2003-05-02
More information about the linux-audio-user