7 Oct
2006
7 Oct
'06
5:30 p.m.
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/…
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
7 Oct
7 Oct
10:36 p.m.
New subject: [linux-audio-user] Midi data arrives, but gets stuck in ALSA's buffer
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/….
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/…
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
8 Oct
8 Oct
12:34 a.m.
New subject: [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/….
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/…
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
8:34 a.m.
New subject: [linux-audio-user] Midi data arrives, but gets stuck in ALSA's buffer
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. 
2:01 p.m.
New subject: [linux-audio-user] Midi data arrives, but gets stuck in ALSA's buffer
On Sun, 2006-10-08 at 12:34 +0200, Pedro Lopez-Cabanillas wrote:
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.
How exactly is the M-Audio firmware not standards compliant? I thought
that the snd-usb-audio driver only supported standards compliant
devices?
Lee
6649
days inactive
6650
days old
linux-audio-user@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Jens Gulden -
Lee Revell -
Pedro Lopez-Cabanillas