| blob | dc822e513bc81d9ac7c92826f4b6c970669ddae8 |
1 .\" $NetBSD: midi.4,v 1.28 2008/04/30 13:10:54 martin Exp $
2 .\"
3 .\" Copyright (c) 1999-2006 The NetBSD Foundation, Inc.
4 .\" All rights reserved.
5 .\"
6 .\" This code is derived from software contributed to The NetBSD Foundation
7 .\" by Lennart Augustsson and Chapman Flack.
8 .\"
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that the following conditions
11 .\" are met:
12 .\" 1. Redistributions of source code must retain the above copyright
13 .\" notice, this list of conditions and the following disclaimer.
14 .\" 2. Redistributions in binary form must reproduce the above copyright
15 .\" notice, this list of conditions and the following disclaimer in the
16 .\" documentation and/or other materials provided with the distribution.
17 .\"
18 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21 .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
22 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28 .\" POSSIBILITY OF SUCH DAMAGE.
29 .\"
30 .Dd May 6, 2006
31 .Dt MIDI 4
32 .Os
33 .Sh NAME
34 .Nm midi
35 .Nd device-independent MIDI driver layer
36 .Sh SYNOPSIS
37 .Cd "midi* at midibus?"
38 .Cd "midi* at pcppi?"
39 .Cd "pseudo-device sequencer"
40 .Pp
41 .In sys/types.h
42 .In sys/midiio.h
43 .Sh DESCRIPTION
44 The
45 .Nm
46 driver is the machine independent layer over anything that can
47 source or sink a
48 .Tn MIDI
49 data stream, whether a physical
50 .Tn "MIDI IN"
51 or
52 .Tn "MIDI OUT"
53 jack on a soundcard, cabled to some external synthesizer or input controller,
54 an on-board programmable tone generator, or a single jack, synthesizer, or
55 controller component within a complex
56 .Tn USB
57 or
58 .Tn IEEE1394
59 .Tn MIDI
60 device that has several
61 such components and appears as several
62 .Tn MIDI
63 streams.
64 .Ss Concepts
65 One
66 .Tn MIDI
67 data stream is a unidirectional stream of
68 .Tn MIDI
69 messages, as could be carried over one
70 .Tn MIDI
71 cable in the
72 .Tn "MIDI 1.0"
73 specification.
74 Many
75 .Tn MIDI
76 messages
77 carry a four-bit channel number, creating up to 16
78 .Tn MIDI
79 channels within a single
80 .Tn MIDI
81 stream.
82 There may be multiple consumers of a
83 .Tn MIDI
84 stream, each configured
85 to react only to messages on specific channels; the sets of channels different
86 consumers react to need not be disjoint.
87 Many modern devices such as multitimbral keyboards and tone generators
88 listen on all 16 channels, or may be viewed as collections of 16
89 independent consumers each listening on one channel.
90 .Tn MIDI
91 defines some messages that take no channel number, and
92 apply to all consumers of the
93 stream on which they are sent.
94 For an inbound stream,
95 .Nm
96 is a promiscuous
97 receiver, capturing all messages regardless of channel number.
98 For an outbound stream, the writer can specify a channel number
99 per message; there is no notion of binding the stream to one
100 destination channel in advance.
101 .Pp
102 A single
103 .Nm
104 device instance is the endpoint of one outbound stream, one
105 inbound stream, or one of each.
106 In the third case, the write and read sides are independent
107 .Tn MIDI
108 streams.
109 For example, a soundcard driver may map its
110 .Tn "MIDI OUT"
111 and
112 .Tn "MIDI IN"
113 jacks to the write and read sides of a single device instance, but
114 those jacks can be cabled to completely different pieces of gear.
115 Information from
116 .Xr dmesg 8 ,
117 and a diagram of any external
118 .Tn MIDI
119 cabling, will help clarify the mapping.
120 .Ss "Underlying drivers and MIDI protocol"
121 Drivers
122 .Nm
123 can attach include soundcard drivers, many of
124 which support a
125 .Tn UART
126 resembling Roland's
127 .Tn MPU401
128 and handled by
129 .Xr mpu 4 ,
130 .Tn "USB MIDI"
131 devices via
132 .Xr umidi 4 ,
133 and on-board devices that can make sounds,
134 whether a lowly
135 .Tn PC
136 speaker or a Yamaha
137 .Tn OPL .
138 Serial port and
139 .Tn IEEE1394
140 connections are currently science fiction.
141 .Pp
142 The
143 .Tn MIDI
144 protocol permits some forms of message compression such as running
145 status and hidden note-off.
146 Received messages on inbound streams are always canonicalized by
147 .Nm
148 before presentation to higher layers.
149 Messages for transmission are accepted by
150 .Nm
151 in any valid form.
152 .Ss "Device access"
153 Access to
154 .Nm
155 device instances can be through the raw device nodes,
156 .Pa /dev/rmidiN ,
157 or through the sequencer,
158 .Pa /dev/music .
159 .Ss "Raw MIDI access"
160 A
161 .Pa /dev/rmidiN
162 device supports
163 .Xr read 2 ,
164 .Xr write 2 ,
165 .Xr ioctl 2 ,
166 .Xr select 2 Ns / Ns
167 .Xr poll 2
168 and the corresponding
169 .Xr kevent 2
170 filters,
171 and may be opened
172 only when it is not already open.
173 It may be opened in
174 .Dv O_RDONLY ,
175 .Dv O_WRONLY ,
176 or
177 .Dv O_RDWR
178 mode, but a later
179 .Xr read 2
180 or
181 .Xr write 2
182 will return \-1 if the device has no associated
183 input or output stream, respectively.
184 .Pp
185 Bytes written are passed as quickly as possible to the underlying driver
186 as complete
187 .Tn MIDI
188 messages; a maximum of two bytes at the end of a
189 .Xr write 2
190 may remain buffered if they do not complete a message, until
191 completed by a following
192 .Xr write 2 .
193 .Pp
194 A
195 .Xr read 2
196 will not block or return
197 .Er EWOULDBLOCK
198 when it could immediately return any nonzero count, and
199 .Tn MIDI
200 messages received are available to
201 .Xr read 2
202 as soon as they are complete,
203 with a maximum of two received bytes remaining buffered if they do not
204 complete a message.
205 .Pp
206 As all
207 .Tn MIDI
208 messages are three bytes or fewer except for System Exclusive,
209 which can have arbitrary length, these rules imply that System Exclusive
210 messages are the only ones of which some bytes can be delivered before
211 all are available.
212 .Pp
213 System Realtime messages are passed with minimum delay in either direction,
214 ahead of any possible buffered incomplete message.
215 As a result, they will never interrupt any
216 .Tn MIDI
217 message except possibly System Exclusive.
218 .Pp
219 A
220 .Xr read 2
221 with a buffer large enough to accommodate the first complete
222 message available will be satisfied with as many complete messages as
223 will fit.
224 A buffer too small for the first complete
225 message will be filled to capacity.
226 Therefore, an application that reads from an
227 .Pa rmidi
228 device with buffers of three bytes or larger need never parse
229 across read boundaries to assemble a received message, except possibly in
230 the case of a System Exclusive message.
231 However, if the application reads through a buffering layer such as
232 .Xr fread 3 ,
233 this property will not be preserved.
234 .Pp
235 The
236 .Nm
237 driver itself supports the
238 .Xr ioctl 2
239 operations
240 .Dv FIOASYNC ,
241 .Dv FIONBIO ,
242 and
243 .Dv FIONREAD .
244 Underlying devices may support others.
245 The value returned for
246 .Dv FIONREAD
247 reflects the size in bytes of complete messages
248 (or System Exclusive chunks) ready to read.
249 If the
250 .Xr ioctl 2
251 returns
252 .Va n
253 and a
254 .Xr read 2
255 of size
256 .Va n
257 is issued,
258 .Va n
259 bytes will be read, but if a
260 .Xr read 2
261 of
262 size
263 .Va m
264 \*[Lt]
265 .Va n
266 is issued, fewer than
267 .Va m
268 bytes may be read if
269 .Va m
270 does not fall
271 on a message/chunk boundary.
272 .Pp
273 Raw
274 .Tn MIDI
275 access can be used to receive bulk dumps from synthesizers, download
276 bulk data to them, and so on.
277 Simple patching of one device to another can be
278 done at the command line, as with
279 .Dl $ cat -u 0\*[Lt]\*[Gt]/dev/rmidi0 1\*[Gt]\*[Am]0
280 which will loop all messages received on the input stream of
281 .Pa rmidi0
282 input stream back to its output
283 stream in real time.
284 However, an attempt to record and play back music with
285 .Dl $ cat /dev/rmidiN \*[Gt]foo; cat foo \*[Gt]/dev/rmidiN
286 will be disappointing.
287 The file
288 .Pa foo
289 will contain all of the notes that were played, but because
290 .Tn MIDI
291 messages carry
292 no explicit timing, the
293 .Sq "playback"
294 will reproduce them all at once, as fast as
295 they can be transmitted.
296 To preserve timing information, the sequencer device can be used.
297 .Ss "Active Sensing"
298 The
299 .Tn MIDI
300 protocol includes a keepalive function called Active Sensing.
301 In any receiver that has
302 .Em not
303 received at least one Active Sense
304 .Tn MIDI
305 message, the
306 feature is suppressed and no timeout applies.
307 If at least one such message has
308 been received, the lapse of any subsequent 300 ms interval without receipt of
309 any message reflects loss of communication, and the receiver should silence any
310 currently sounding notes and return to non-Active-Sensing behavior.
311 A sender using Active Sensing generally avoids 300 ms gaps in
312 transmission by sending Active Sense messages (which have no other
313 effect) as needed when there is no other traffic to send in the
314 interval.
315 This feature can be important for
316 .Tn MIDI ,
317 which relies on separate Note On and Note Off messages, to avoid notes stuck on
318 indefinitely if communication is interrupted before a Note Off
319 message arrives.
320 .Pp
321 This protocol is supported in
322 .Nm .
323 An outbound stream will be kept alive
324 by sending Active Sense messages as needed, beginning after any real
325 traffic is sent on the stream, and continuing until the stream is closed.
326 On an inbound stream, if any Active Sense has been received, then a process
327 reading an
328 .Pa rmidi
329 device will see an end-of-file indication if the input timeout elapses.
330 The stream remains open, the driver reverts to enforcing no timeout, and the
331 process may continue to read for more input.
332 Subsequent receipt of an
333 Active Sense message will re-arm the timeout.
334 As received Active Sense messages are handled by
335 .Nm ,
336 they are not included among messages read from the
337 .Pa /dev/rmidiN
338 device.
339 .Pp
340 These rules support end-to-end Active Sensing behavior in simple cases
341 without special action in an application.
342 For example, in
343 .Dl $ cat -u /dev/rmidi0 \*[Gt]/dev/rmidi1
344 if the input stream to
345 .Pa rmidi0
346 is lost, the
347 .Xr cat 1
348 command exits; on the
349 .Xr close 2
350 of
351 .Pa rmidi1 ,
352 .Nm
353 ceases to send Active Sense messages, and the receiving
354 device will detect the loss and silence any outstanding notes.
355 .Ss "Access through the sequencer"
356 To play music using the raw
357 .Tn MIDI
358 .Tn API
359 would require an application to
360 issue many small writes with very precise timing.
361 The sequencer device,
362 .Pa /dev/music ,
363 can manage the timing of
364 .Tn MIDI
365 data in the kernel, to avoid
366 such demanding real-time constraints on a user process.
367 .Pp
368 The
369 .Pa /dev/music
370 device can be opened only when it is not already open.
371 When opened, the sequencer internally opens all
372 .Tn MIDI
373 instances existing
374 in the system that are not already open at their raw nodes; any attempts
375 to open them at their raw nodes while the sequencer is open will fail.
376 All access to the corresponding
377 .Tn MIDI
378 streams will then be through the
379 sequencer.
380 .Pp
381 Reads and writes of
382 .Pa /dev/music
383 pass eight-byte event structures defined in
384 .Aq Pa sys/midiio.h
385 (which see for their documentation and examples of use).
386 Some events correspond to
387 .Tn MIDI
388 messages, and carry an integer
389 .Va device
390 field to identify one of the
391 .Tn MIDI
392 devices opened by the sequencer.
393 Other events carry timing information interpreted or generated by the
394 sequencer itself.
395 .Pp
396 A message received on an input stream is wrapped in a sequencer event
397 along with the device index of the stream it arrived on, and queued for
398 the reader of
399 .Pa /dev/music .
400 If a measurable time interval passed since the
401 last preceding message, a timing event that represents a delay for that interval
402 is queued ahead of the received event.
403 The sequencer handles output events by
404 interpreting any timing event, and routing any
405 .Tn MIDI
406 message event at the proper time to
407 an underlying output stream according to its
408 .Va device
409 index.
410 Therefore
411 .Dl $ cat /dev/music \*[Gt]foo; cat foo \*[Gt]/dev/music
412 can be expected to capture and reproduce an input performance including
413 timing.
414 .Pp
415 The process of playing back a complex
416 .Tn MIDI
417 file is illustrated below.
418 The file may contain several tracks\(emfour, in this example\(emof
419 .Tn MIDI
420 events, each marked with a device index and a time stamp, that may
421 overlap in time.
422 In the example,
423 .Va a ,
424 .Va b ,
425 and
426 .Va c
427 are device indices of
428 the three output
429 .Tn MIDI
430 streams; the left-hand digit in each input event represents a
431 .Tn MIDI
432 channel on the selected stream, and the right-hand digit represents
433 a time for the event's occurrence.
434 As illustrated, the input tracks are not firmly associated with
435 output streams; any track may contain events for any stream.
436 .Bd -literal
437 | | a2|4 |
438 a0|3 | c1|3 c0|3
439 | b0|2 b1|2 |
440 | b1|1 | c0|1
441 a0|0 | b0|0 |
442 v v v v
443 +---------------------------+
444 | merge to 1 ordered stream |
445 | user code, eg midiplay(1) |
446 +---------------------------+
447 b1|2
448 b0|2
449 c0|1
450 b1|1
451 b0|0
452 a0|0
453 v
454 _______+-------------+_______user
455 | /dev/music | kernel
456 | (sequencer) |
457 +-------------+
458 | 1 0
459 +-----' | '-----.
460 0 0 |
461 v v v
462 +-------+ +--------+ +---------+
463 |midi(4)| |midi(4) | |midi(4) |
464 |rmidia | |rmidib | |rmidic |
465 +-------+ +--------+ +---------+
466 | mpu(4)| |umidi(4)| |midisyn |
467 +-------+ +--------+ +---------+
468 | HW | | | opl(4) |
469 | MIDI | U +---------+
470 | UART | S | internal|
471 +-------+ B | tone |
472 | | |generator|
473 v | +---------+
474 external v
475 MIDI device external
476 MIDI device
477 .Ed
478 .Pp
479 A user process must merge the tracks into a single stream of sequencer
480 .Tn MIDI
481 and timing events in order by desired timing.
482 The sequencer obeys the timing events and distributes the
483 .Tn MIDI
484 events to the three destinations,
485 in this case two external devices connected to a sound card
486 .Tn UART
487 and a
488 .Tn USB
489 interface, and an
490 .Tn OPL
491 tone generator on a sound card.
492 .Sh NOTES
493 Use of
494 .Xr select 2 Ns / Ns
495 .Xr poll 2
496 with the sequencer is supported, however, there is no guarantee that a
497 .Xr write 2
498 will not block or return
499 .Er EWOULDBLOCK
500 if it begins with a timer-wait event, even if
501 .Xr select 2 Ns / Ns
502 .Xr poll 2
503 reported the sequencer writable.
504 .Pp
505 The delivery of a realtime message ahead of buffered bytes of an incomplete
506 message may cause the realtime message to seem, in a saved byte stream, to have
507 arrived up to 640 us earlier than it really did, at
508 .Tn MIDI
509 1.0 data rates.
510 Higher data rates make the effect less significant.
511 .Pp
512 Another sequencer device,
513 .Pa /dev/sequencer ,
514 is provided only for backward
515 compatibility with an obsolete
516 .Tn OSS
517 interface in which some sequencer events
518 were four-byte records.
519 It is not further documented here, and the
520 .Pa /dev/music
521 .Tn API
522 should be used in new code.
523 The
524 .Pa /dev/sequencer
525 emulation is implemented only for writing, and that might not be complete.
526 .Sh IMPLEMENTATION NOTES
527 Some hardware devices supporting
528 .Nm
529 lack transmit-ready interrupts, and some have the capability in
530 hardware but currently lack driver support.
531 They can be recognized by the annotation
532 .Li "(CPU-intensive output)"
533 in
534 .Xr dmesg 8 .
535 While suitable for music playback, they may have an objectionable impact on
536 system responsiveness during bulk transmission such as patch downloads, and
537 are best avoided for that purpose if other suitable devices are present.
538 .Pp
539 Buffer space in
540 .Nm
541 itself is adequate for about 200 ms of traffic at
542 .Tn "MIDI 1.0"
543 data rates, per stream.
544 .Pp
545 Event counters record bytes and messages discarded because of protocol
546 errors or buffer overruns, and can be viewed with
547 .Li "vmstat -e" .
548 They can be useful in diagnosing flaky cables and other communication
549 problems.
550 .Pp
551 .\" These two paragraphs really belong not here but in a midi(9) man page,
552 .\" which should one day exist.
553 A raw sound generator uses the
554 .Sy midisyn
555 layer to present a
556 .Tn MIDI
557 message-driven interface attachable by
558 .Nm .
559 .Pp
560 While
561 .Nm
562 accepts messages for transmission in any valid mixture of compressed
563 or canonical form, they are always presented to an underlying driver
564 in the form it prefers.
565 Drivers for simple
566 .Tn UART Ns -like
567 devices
568 register their preference for a compressed byte stream, while those like
569 .Xr umidi 4 ,
570 which uses a packet protocol, or
571 .Sy midisyn ,
572 which interprets complete
573 messages, register for intact canonical messages.
574 This design eliminates the
575 need for compression and canonicalization logic from all layers above and below
576 .Nm
577 itself.
578 .Sh FILES
579 .Bl -tag -width /dev/sequencer -compact
580 .It Pa /dev/rmidiN
581 .It Pa /dev/music
582 .It Pa /dev/sequencer
583 .El
584 .Sh ERRORS
585 In addition to other errors documented for the
586 .Xr write 2
587 family of system calls,
588 .Er EPROTO
589 can be returned if the bytes to be written on a raw
590 .Nm
591 device would violate
592 .Tn MIDI
593 protocol.
594 .Sh SEE ALSO
595 .Xr midiplay 1 ,
596 .Xr ioctl 2 ,
597 .Xr ossaudio 3 ,
598 .Xr audio 4 ,
599 .Xr mpu 4 ,
600 .Xr opl 4 ,
601 .Xr umidi 4
602 .Pp
603 For ports using the ISA bus:
604 .Xr cms 4 ,
605 .Xr pcppi 4 ,
606 .Xr sb 4
607 .Pp
608 For ports using the PCI bus:
609 .Xr autri 4 ,
610 .Xr clcs 4 ,
611 .Xr eap 4
612 .Sh HISTORY
613 The
614 .Nm
615 driver first appeared in
616 .Nx 1.4 .
617 It was overhauled and this manual page rewritten for
618 .Nx 4.0 .
619 .Sh BUGS
620 Some
621 .Tn OSS
622 sequencer events and
623 .Xr ioctl 2
624 operations are unimplemented, as
625 .Aq Pa sys/midiio.h
626 notes.
627 .Pp
628 .Tn OSS
629 source-compatible sequencer macros should be added to
630 .Aq Pa sys/soundcard.h ,
631 implemented with the
632 .Nx
633 ones in
634 .Aq Pa sys/midiio.h ,
635 so sources written for OSS can be easily compiled.
636 .Pp
637 The sequencer blocks (or returns
638 .Er EWOULDBLOCK )
639 only when its buffer physically fills, which can represent an arbitrary
640 latency because of buffered timing events.
641 As a result, interrupting a process writing the sequencer may not
642 interrupt music playback for a considerable time.
643 The sequencer could enforce a reasonable latency bound
644 by examining timing events as they are enqueued and blocking appropriately.
645 .Pp
646 .Dv FIOASYNC
647 enables signal delivery to the calling process only;
648 .Dv FIOSETOWN
649 is not supported.
650 .Pp
651 The sequencer can only be a timing master, but does not send timing messages
652 to synchronize any slave device; it cannot be slaved to timing messages
653 received on any interface (which would presumably require a PLL algorithm
654 similar to NTP's, and expertise in that area to implement it).
655 The sequencer ignores timing messages received on any interface
656 and does not pass them along to the reading process, and the OSS
657 operations to change that behavior are unimplemented.
658 .Pp
659 The
660 .Dv SEQUENCER_TMR_TIMEBASE
661 .Xr ioctl 2
662 will report successfully setting any
663 timebase up to ridiculously high resolutions, though the actual
664 resolution, and therefore jitter, is constrained by
665 .Xr hz 9 .
666 Comparable sequencer implementations typically allow a selection from available
667 sources of time interrupts that may be programmable.
668 .Pp
669 The device number in a sequencer event is treated on
670 .Xr write 2
671 as index into
672 the array of
673 .Tn MIDI
674 devices the sequencer has opened, but on
675 .Xr read 2
676 as the
677 unit number of the source
678 .Tn MIDI
679 device; these are usually the same if the
680 sequencer has opened all the
681 .Tn MIDI
682 devices (that is, none was already open
683 at its raw node when the sequencer was opened), but might not be the same
684 otherwise.
685 .Pp
686 There is at present no way to make reception nonpromiscuous,
687 should anyone have a reason to want to.
688 .Pp
689 There should be ways to override default Active Sense behavior.
690 As one obvious
691 case, if an application is seen to send Active Sense explicitly,
692 .Nm
693 should refrain
694 from adding its own.
695 On receive, there should be an option to pass Active Sense through
696 rather than interpreting it, for apps that wish to handle or ignore it
697 themselves and never see
698 .Dv EOF .
699 .Pp
700 When a
701 .Nm
702 stream is open by the sequencer, Active Sense messages received on the stream
703 are passed to the sequencer and not interpreted by
704 .Nm .
705 The sequencer at present neither does anything itself with Active Sense
706 messages received, nor supports the
707 .Tn OSS
708 .Tn API
709 for making them available to the user process.
710 .Pp
711 System Exclusive messages can be received by reading a raw device, but
712 not by reading the sequencer; they are discarded on receipt when the
713 stream is open by the sequencer, rather than being presented as the
714 OSS-defined sequencer events.
715 .Pp
716 .Sy midisyn
717 is too rudimentary at present to get satisfactory results from any
718 onboard synth.
719 It lacks the required special interpretation of the
720 General
721 .Tn MIDI
722 percussion channel in GM mode.
723 More devices should be supported; some sound cards with synthesis
724 capability have
725 .Nx
726 drivers that implement the
727 .Xr audio 4
728 but not the
729 .Sy midisyn
730 interface.
731 Voice stealing algorithm does not follow the General
732 .Tn MIDI
733 Developer Guidelines.
734 .Pp
735 .Tn ALSA
736 sequencer compatibility is lacking, but becoming important to applications.
737 It would require the function of merging multiple tracks into a single ordered
738 stream to be moved from user space into the sequencer.
739 Assuming the sequencer driven by periodic interrupts, timing wheels
740 could be used as in
741 .Xr hardclock 9
742 itself.
743 Similar functionality will be in OSS4; with the right infrastructure
744 it should be possible to support both.
745 When merging
746 .Tn MIDI
747 streams, a notion of transaction
748 is needed to group critical message sequences.
749 If
750 .Tn ALSA
751 or
752 .Tn OSS4
753 have no such notion, it should be provided as an upward-compatible
754 extension.
755 .Pp
756 I would rather have
757 .Xr open 2
758 itself return an error (by the POSIX description
759 .Er ENODEV
760 looks most appropriate) if a read or write mode
761 is requested that is not supported by the instance, rather than letting
762 .Xr open 2
763 succeed and
764 .Xr read 2
765 or
766 .Xr write 2
767 return \-1, but so help me, the latter seems
768 the more common
769 .Ux
770 practice.