15 Feb
2005
15 Feb
'05
4:58 p.m.
Hi,
since the first tests while developing Sysexxer, which
unfortunately uses /dev/midi instead being an ALSA sequencer
client, I saw a thing which still remains.
When receiving a complete sysex bank from the Access Virus,
the first three bytes are sometimes missing.
This does not depend on sysexxer, but also appears when I do a
cat /dev/midi > sysexfile.syx
I'm using an Edirol UM-1S, a one in one out USB2MIDI device
with Advanced Linux Sound Architecture Driver Version 1.0.6
(Sun Aug 15 07:17:53 2004 UTC). Compiled on Jan 26 2005 for
kernel 2.6.10ce (SMP).
I have disabled all OSS stuff in the Kernel config, and I even
ensured that the OSS USB-MIDI driver is disabled there.
Did anybody else make this experience? Anyone else using
SysExxer?
A Friend politely wrote SysExxer for me. Unfortunately, he was
not that familiar with ALSA so he prepared a second sound
system in the code but he denied to write the ALSA code.
Someone here who'd like to add the missing code (in the hope
this fixes the problem above)?
Best regards
ce
16 Feb
16 Feb
12:35 p.m.
Christoph Eckert wrote:
When receiving a complete sysex bank from the Access
Virus,
the first three bytes are sometimes missing.
The USB MIDI protocol has three sysex bytes per packet, so it seems
the first packet gets dropped for some reason.
If you're using a UHCI(?) controller and this happens the first time
you're receiving data after having unloaded the driver before, this
may be a bug in the kernel. A workaround would be to reload the USB
drivers(s), too.
This does not depend on sysexxer, but also appears
when I do a
cat /dev/midi > sysexfile.syx
Using ALSA, this would be "amidi -p portname -r sysexfile.syx".
HTH
Clemens
5:30 p.m.
Hi,
The USB MIDI protocol has three sysex bytes per
packet, so
it seems the first packet gets dropped for some reason.
ah, interesting info.
If you're using a UHCI(?) controller
I find
ohci_hcd 23560 0
ehci_hcd 34692 0
ohci1394 35716 0
ieee1394 312376 2 eth1394,ohci1394
uhci_hcd 35216 0
To be honest, I do not know if I really need both uhci and
ohci; I guess not?
and this happens the
first time you're receiving data after having unloaded the
driver before, this may be a bug in the kernel. A
workaround would be to reload the USB drivers(s), too.
I'll do some tests the next days. Maybe I'll wait because I
just ordered a new USB-MIDI-Patchbay and I'd like to do the
tests with it, so I can ensure it does not depend on my
current Edirol UM-1S.
Best regards
ce
17 Feb
17 Feb
5:06 p.m.
I'll do some tests the next days. Maybe I'll
wait because I
just ordered a new USB-MIDI-Patchbay and I'd like to do the
tests with it, so I can ensure it does not depend on my
current Edirol UM-1S.
Rrrrrr.
I wanted to do some test cases, but of course everything
behaved as *un*expected: it simply worked ;-) .
All SysEx events have been properly received, even after a
reboot, even with plugged in devices during boot time and
even with not plugged in devices.
If it were a kernel bug, it will be difficult to find if it
only happens in certain conditions.
If it appears again, I'll do some further testing.
Thanks & best regards
ce
18 Feb
18 Feb
5:02 a.m.
Christoph Eckert wrote:
I've done some further testing, and it seems it is not a kernel bug
but an issue with Edirol devices. Apparently, they haven't been
designed for drivers that can be unloaded and reloaded. I'll see if I
can change the driver to explicitly reset the device when loading.
Clemens
I'll do
some tests the next days. Maybe I'll wait because I
just ordered a new USB-MIDI-Patchbay and I'd like to do the
tests with it, so I can ensure it does not depend on my
current Edirol UM-1S.
Rrrrrr.
I wanted to do some test cases, but of course everything
behaved as *un*expected: it simply worked ;-) .
All SysEx events have been properly received, even after a
reboot, even with plugged in devices during boot time and
even with not plugged in devices.
If it were a kernel bug, it will be difficult to find if it
only happens in certain conditions.
4:58 p.m.
Hi,
I've done some further testing, and it seems it is
not a
kernel bug but an issue with Edirol devices. Apparently,
they haven't been designed for drivers that can be unloaded
and reloaded. I'll see if I can change the driver to
explicitly reset the device when loading.
well, as I'm still running all 5 MIDI devices on one MIDI
'bus', I'm going to buy a 8x8 patchbay for better timing (and
to use multimodes of the devices more excessively), so I hope
the problem will be solved this way.
I have read some device manuals, and it seems that it'll be a
midisport 8x8. I already have installed the firmware loader
(thanks to the author, BTW ;-), and even if the handling on
linux is a bit difficult, I liked the midisport due to the
fact that it can act as a real merge bay in offline mode.
The only thing that still keeps me without the device is the
price - I have no problem paying lots of money for synths,
but a MIDI device is somehow a piece of hardware I do not
like to spend money for ;-) .
Best regards
ce
7224
days inactive
7227
days old
linux-audio-user@lists.linuxaudio.org
5 comments
2 participants
participants (2)
-
Christoph Eckert -
Clemens Ladisch