I seem to have Real-time MIDI input working with Csound, and would like to
post what I've found, since others have been having problems as well. I'd
like people to read through this and tell me if I'm mistaken on anything:

(1) MIDI input does not work with the USS lite driver (at least the one that
ships with RedHat 4.0). This is because that driver ignores the O_NDELAY
call and blocks on every read(). The author tells me that there is an Ioctl
parameter to set the maximum time the driver will wait before returning -
however, the minimum time is 10ms. Since I don't think that this is a
tolerable situation in our case, I decided to try the driver that is
packaged with TclMIDI (Thanks Toby!).

(2) I had better luck with the TclMIDI driver. For one, it seems to be
better documented. Remember to use the raw Midi input device ( -M
/dev/rdmidi0 ), and not the time-stamped input device. As Matti had told me
(Thanks Matti!), I needed to rebuild the USS sound-driver module to *not*
include MIDI driver support. This is because I am still using the USS Gravis
Ultrasound driver (since the TclMIDI doc says that theirs is not up to
speed). And unfortunately, the USS stuff is all in one module, so opening
the sound card otherwise would try to open both MIDI drivers - an IRQ
conflict message in the log is the symptom.

(3) I was puzzled that when using small buffer sizes (-b and -B options),
that I still had very long delays. It turns out that this is because the
soundcard DSP_SETBLCKSIZE (not sure if this is the right spelling) ioctl
parameter only sets both the fragment size, which is really the DMA buffer
size that is used, and the number of fragments to use. CSound ORs this size
with 0x7fff0000, which tells the driver to use as many of these fragments as
there is room in the buffer size you set up when you compiled the driver.
Thus, for real-time performance you want to change the 0x7fff to 0x0002, to
use only two fragments (one is being DMA'd to the card while the other is
being written by CSound). I apologize for not having the code in front of me
- anyone who can't find the place, please let me know. 

(4) I found "strace" to be very helpfull. With the -r and -T flags, you can
show all the timing information the I/O calls, to see how will CSound is
keeping up. 

(5) Linux now supports the POSIX scheduling policies of SCHED_FIFO and
SCHED_RR. ( See doc for sched_setscheduler() ). Any process that is set
SCHED_FIFO will run as a real-time process, which means it will always run
as long as it is runnable, and will not be interrupted by non-realtime tasks
(SCHED_OTHER , the default). I haven't tried this yet, but will do it soon.
One danger is that a SCHED_FIFO task can effectively lock up the system, and
this has to be dealt with somehow.

Larry Troxler
lt@westnet.com