Subject: kern/32442: improved midi(4) input state machine and debug hooks
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: None <nbgnats@anastigmatix.net>
List: netbsd-bugs
Date: 01/03/2006 04:00:00
>Number:         32442
>Category:       kern
>Synopsis:       improved midi(4) input state machine and debug hooks
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 03 04:00:00 +0000 2006
>Originator:     Chapman Flack
>Release:        2.0
>Organization:
>Environment:
NetBSD lundestad.anastigmatix.net 2.0 NetBSD 2.0 (lundestad) #31: Mon Jan  2 21:06:07 EST 2006  xxx@xxx:/usr/src/sys/arch/i386/compile/lundestad i386
>Description:
While working on kern/32441 I found it useful to replace the input
state machine in midi.c with a full pedantically correct one that can
detect protocol errors in the input, count them, and shield the reading
client from them. (A message that is incomplete due to a protocol error
is now completely dropped so the client doesn't have to parse and
recover from a partial message. The only message that doesn't work for
is SysEx, which can be of arbitrary length so there's no way to ensure
the client hasn't seen some of it, but at least the client only has to
handle one error case in SysEx.)

All real-time messages now correctly pass through with no effect on
the state machine, and all non-real-time System Common messages now
correctly cancel running status. Because the old state machine did
miss those details, I've decided to class this as a bug rather than
enh, but it's a pretty near thing.

I also changed the debug levels for a number of DPRINTFNs (and
documented the levels) so it's easier to get the information you want.

Active Sense used to be unconditionally dropped in midi_in. Now,
if the sequencer is open, Active Sense gets forwarded to the sequencer
(which currently drops it, but that's one step closer to making the
sequencer do something useful with it, or to implement the OSS
sequencer ioctls that make Active Sense visible).

THE REST OF THIS NOTE IS FOR DISCUSSION OF FUTURE WORK IDEAS; these
are not included in the current patch.

If only the raw midi device is being read, midi_in still drops any
Active Sense messages, as before. That's not always ideal--if you're
doing cat rmidi1 >rmidi2 you do want the active sense messages to be passed through, so the machine on rmidi2 will know to stop if you trip
on the cable.  On the other hand, if you're just trying to capture
data to a file you don't want it filled with sense codes.  I think
there ought to be a way to choose whether to pass or drop active
sense even with the rmidi device, an ioctl perhaps, or a different
device node (so you can make the decision just by which device you
cat, and not have to fuss with ioctl). I'm not aware that OSS addressed the issue so it'd be a bit of departure from the OSS API.

The same considerations apply to other realtime messages too, like
timing clock, which currently is passed through to rmidi, and will
fill a file even quicker than active sense.  Perhaps there should just
be two device nodes, one that passes /all/ received messages, and
one that filters out /all/ realtime messages from the stream. Anyway,
all that's for another day.
>How-To-Repeat:
open a midi port for reading and feed it a data stream with any of
the following properties:

- real-time messages interspersed in streams of running status
  (running status is interrupted, which is incorrect)

- System Common messages followed (incorrectly) by data bytes
  (treated as running status, which is incorrect)

- dropped bytes (lack of protocol error detection and resynchronization
  can pass an awful mess on to the reading client)
>Fix:
http://www.anastigmatix.net/cvsweb.cgi/NetBSD/mididfa.pat

Patch is with respect to 2.0 sources, but as for the 32441 patch I
see in webcvs that there has not been much conflicting work on the
affected files.  Looks like there will be about 9 conflicts involving
DPRINTFN lines that have had minor changes. :)