Well, yes, similar in intent but not in implementation, although
perhaps related. There is currently no support in the OSS-derived
sound driver for opening a device that corresponds to a MIDI interface
to an on-board synth (particularly the OPL/3). The assumption is that
you open /dev/sequencer{,2}, and then get "device numbers" using an
ioctl, and then subsequently route MIDI data to that device by setting
"devno" in the event structure used by the sequencer interface. This
has very little to do with providing a MIDI interface that can be used
by more generic programs, those that want to open something like
/dev/midiNN, and write legal MIDI bytes to the resulting file
descriptor.
Another example: if I want to run an application that provides
realtime (graphical, perhaps) control of a on-board synth via a
specialized device driver for that soundcard/synth, right now I have
to open /dev/sequencer{,2}, and then use ioctl's on the fd to send
SNDCTL_SYNTH_CONTROL messages. Thats OK, until I want to start an
actual sequencer application that will also want to open
/dev/sequence{,2}. This is a stupid, stupid limitation. Having to
access synth "devices" (as opposed to their MIDI "interface") via
/dev/sequencer,{2} is a big mistake. /dev/sequencer{,2} should be
providing a mechanism for timing, not the major means of access to a
device.
Thus, I also think there should be:
/dev/sound/synthNN
or even just
/dev/synthNN
and perhaps
/dev/gusNN
/dev/wavefrontNN
/dev/pasNN
/dev/fill-in-your-on-board-synth-name-0
as well.
These are for use by applications that want direct control over the
synth, not MIDI access to it.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html