Subject: sequencer dropouts?
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 07/17/2003 20:48:49
I have a piano with MIDI capability and I have an i386 machine with a
MIDI-capable soundblaster. I recently picked up the requisite
interface electronics and some cables, and now I have some peculiar
(mis)behaviour to report and ask for help with.
The symptom is that some notes get lost - but only late in a
performance. I wrote a small program which is basically
"cat > /dev/music" except that it first does a few ioctls to set up and
start the timer stuff. I have code that generates seq_event_recs,
which are then fed into this program. (Yes, I realize this interface
is suboptimal in various ways. Once I have everything working well I
will probably clean it up.)
However, the piano simply fails to play some notes. I have not managed
to come up with anything approximating a description of exactly which
ones; what I have found is
- It does not appear to be speed-related; it happens even with fairly
slow playing speeds, slow enough that the MIDI output queue never
need get above a couple dozen bytes. (This is relevant because I
think there is a bug that can drop stuff if the MIDI output queue
fills up; midi_writebytes returns EWOULDBLOCK, which is passed up the
return chain until seq_do_command returns it and it gets ignored by
- It is repeatable; a given blob of seq_event_recs fed to the play
program always drops the same notes.
- It is history-dependent; if I take a blob that drops notes in the
second half, and extract the second half and play it by itself, it
drops less than it did when it was part of the larger blob.
- It appears to be software; if I take two blobs and play them
separately with a delay between them, then paste them together with a
delay record of the same nominal size in between, the latter drops
the same notes up to the point of pasting and drops more notes than
the second blob alone does after that - even though the data stream
headed for the piano is the same except possibly for the exact timing
of the delay. I can't explain this except by assuming it's related
to state somewhere in the software.
I did some diffing of my code with -current's and I didn't see anything
that looked related; all of the diffs appear to be stock subsystem
changes (such as replacing timeouts with callouts).
Any pointers would be most appreciated. I really don't like the idea
of closing and re-opening the sequencer device for each note. :-)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B