Chapman Flack wrote:
> [...] Oddly, the version of the linux driver google found for me
> didn't seem to have the helpful comment you reproduced above,

I added it later. :)  The 'official' CVS repository is at
<http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/>.

> Testing with cat -u </dev/rmidiX >/dev/rmidiY as shown in the midi man page,
> keyboard set for local off, bits can be lost when playing block chords on
> keyboard - many near simultaneous attacks and releases.  The worst part
> is, extraneous very high notes are heard, which suggests to me individual
> bytes are being dropped, creating bogus packets.  I doubt this is any fault
> of the Midisport

It's reported to work fine with Linux/OSX/Windows.

> and I mostly suspect the incredible overhead in the input side of
> umidi->midi, where nice packetized commands are received from the
> Midisport (but in reads no larger than the bare minimum) and
> passed up to midi with *one function call per byte*, where the
> first thing midi does is push them through a state machine to
> repacketize them.  Yuck.

I see no problem with that.  Any function call/state machine overhead
should be lost in the delays due to the USB framing.

> But I have to confirm whether I'm right about where the bottleneck
> is, and that'll happen some other day.

I'm by no means a *BSD expert, but I think the output code has two
problems:

1) The output jack's buffer is for one packet only, so a packet will
overwrite any previous packet that hasn't been sent to the USB yet.

2) The driver uses one USB transfer for each output packet, so the
maximum MIDI bandwith for each endpoint is about 3000 bytes/s (three
MIDI bytes per packet, 1000 frames/s), which is about the same as the
standard MIDI bandwith for _one_ port.  And if the output interrupt
isn't completely handled before the beginning of the next USB frame,
the bandwith is half of that because data is sent each second frame.


BTW: I have found it useful to do the loopback test the other way
around -- connect the MIDI ports, and use a program that blasts away
at the output port and looks if the data arrives again at the input
port.  (The program I used (alsa-lib/test/midiloop.c) uses
Linux-specific APIs, so the implementation is left as an exercise for
the reader. ;-)


Clemens