1audio(7I) Ioctl Requests audio(7I)
2
6 audio - generic audio device interface
7
9 #include <sys/audio.h>
10
13 An audio device is used to play and/or record a stream of audio data.
14 Since a specific audio device may not support all functionality
15 described below, refer to the device-specific manual pages for a com‐
16 plete description of each hardware device. An application can use the
17 AUDIO_GETDEV ioctl(2) to determine the current audio hardware associ‐
18 ated with /dev/audio.
19 The audio framework provides a software mixing engine (audio mixer) for
22 all audio devices, allowing more than one process to play or record
23 audio at the same time.
24 Backward Compatibility
26 It is no longer possible to disable the mixing function. Applications
27 must not assume that they have exclusive access to the audio device.
28 Multi-Stream Codecs
30 The audio mixer supports multi-stream Codecs. These devices have DSP
31 engines that provide sample rate conversion, hardware mixing, and other
32 features. The use of such hardware features is opaque to applications.
33
35 Digital audio data represents a quantized approximation of an analog
36 audio signal waveform. In the simplest case, these quantized numbers
37 represent the amplitude of the input waveform at particular sampling
38 intervals. To achieve the best approximation of an input signal, the
39 highest possible sampling frequency and precision should be used. How‐
40 ever, increased accuracy comes at a cost of increased data storage
41 requirements. For instance, one minute of monaural audio recorded in
42 μ-Law format (pronounced mew-law) at 8 KHz requires nearly 0.5
43 megabytes of storage, while the standard Compact Disc audio format
44 (stereo 16-bit linear PCM data sampled at 44.1 KHz) requires approxi‐
45 mately 10 megabytes per minute.
46 Audio data may be represented in several different formats. An audio
49 device's current audio data format can be determined by using the
50 AUDIO_GETINFO ioctl(2) described below.
51 An audio data format is characterized in the audio driver by four
54 parameters: Sample Rate, Encoding, Precision, and Channels. Refer to
55 the device-specific manual pages for a list of the audio formats that
56 each device supports. In addition to the formats that the audio device
57 supports directly, other formats provide higher data compression.
58 Applications may convert audio data to and from these formats when
59 playing or recording.
60 Sample Rate
62 Sample rate is a number that represents the sampling frequency (in sam‐
63 ples per second) of the audio data.
64 The audio mixer always configures the hardware for the highest possible
67 sample rate for both play and record. This ensures that none of the
68 audio streams require compute-intensive low pass filtering. The result
69 is that high sample rate audio streams are not degraded by filter ing.
70 Sample rate conversion can be a compute-intensive operation, depending
73 on the number of channels and a device's sample rate. For example, an
74 8KHz signal can be easily converted to 48KHz, requiring a low cost up
75 sampling by 6. However, converting from 44.1KHz to 48KHz is compute
76 intensive because it must be up sampled by 160 and then down sampled by
77 147. This is only done using integer multipliers.
78 Applications can greatly reduce the impact of sample rate conversion by
81 carefully picking the sample rate. Applications should always use the
82 highest sample rate the device supports. An application can also do its
83 own sample rate conversion (to take advantage of floating point and
84 accelerated instruction or use small integers for up and down sampling.
85 All modern audio devices run at 48 kHz or a multiple thereof, hence
88 just using 48 kHz may be a reasonable compromise if the application is
89 not prepared to select higher sample rates.
90 Encodings
92 An encoding parameter specifies the audio data representation. μ-Law
93 encoding corresponds to CCITT G.711, and is the standard for voice data
94 used by telephone companies in the United States, Canada, and Japan. A-
95 Law encoding is also part of CCITT G.711 and is the standard encoding
96 for telephony elsewhere in the world. A-Law and μ-Law audio data are
97 sampled at a rate of 8000 samples per second with 12-bit precision,
98 with the data compressed to 8-bit samples. The resulting audio data
99 quality is equivalent to that of standard analog telephone service.
100 Linear Pulse Code Modulation (PCM) is an uncompressed, signed audio
103 format in which sample values are directly proportional to audio signal
104 voltages. Each sample is a 2's complement number that represents a pos‐
105 itive or negative amplitude.
106 Precision
108 Precision indicates the number of bits used to store each audio sample.
109 For instance, u-Law and A-Law data are stored with 8-bit precision. PCM
110 data may be stored at various precisions, though 16-bit is the most
111 common.
112 Channels
114 Multiple channels of audio may be interleaved at sample boundaries. A
115 sample frame consists of a single sample from each active channel. For
116 example, a sample frame of stereo 16-bit PCM data consists of two
117 16-bit samples, corresponding to the left and right channel data.
118 The audio mixer sets the hardware to the maximum number of channels
121 supported. If a mono signal is played or recorded, it is mixed on the
122 first two (usually the left and right) channels only. Silence is mixed
123 on the remaining channels
124 Supported Formats
126 The audio mixer supports the following audio formats:
127 Encoding Precision Channels
129 Signed Linear PCM 32-bit Mono or Stereo
130 Signed Linear PCM 16-bit Mono or Stereo
131 Signed Linear PCM 8-bit Mono or Stereo
132 u-Law 8-bit Mono or Stereo
133 A-Law 8-bit Mono or Stereo
134 The audio mixer converts all audio streams to 24-bit Linear PCM before
139 mixing. After mixing, conversion is made to the best possible Codec
140 format. The conversion process is not compute intensive and audio
141 applications can choose the encoding format that best meets their
142 needs.
143 Note that the mixer discards the low order 8 bits of 32-bit Signed Lin‐
146 ear PCM in order to perform mixing. (This is done to allow for possible
147 overflows to fit into 32-bits when mixing multiple streams together.)
148 Hence, the maximum effective precision is 24-bits.
149
151 The device /dev/audio is a device driver that dispatches audio requests
152 to the appropriate underlying audio hardware. The audio driver is
153 implemented as a STREAMS driver. In order to record audio input, appli‐
154 cations open(2) the /dev/audio device and read data from it using the
155 read(2) system call. Similarly, sound data is queued to the audio out‐
156 put port by using the write(2) system call. Device configuration is
157 performed using the ioctl(2) interface.
158 Because some systems may contain more than one audio device, applica‐
161 tion writers are encouraged to query the AUDIODEV environment variable.
162 If this variable is present in the environment, its value should iden‐
163 tify the path name of the default audio device.
164 Opening the Audio Device
166 The audio device is not treated as an exclusive resource. Each process
167 may open the audio device once.
168 Each open() completes as long as there are channels available to be
171 allocated. If no channels are available to be allocated:
172 o if either the O_NDELAY or O_NONBLOCK flags are set in the
174 open() oflag argument, then -1 is immediately returned, with
175 errno set to EBUSY.
176 o if neither the O_NDELAY nor the O_NONBLOCK flag are set,
178 then open() hangs until the device is available or a signal
179 is delivered to the process, in which case a -1 is returned
180 with errno set to EINTR.
181 Upon the initial open() of the audio channel, the audio mixer sets the
184 data format of the audio channel to the default state of 8-bit, 8Khz,
185 mono u-Law data. If the audio device does not support this configura‐
186 tion, it informs the audio mixer of the initial configuration. Audio
187 applications should explicitly set the encoding characteristics to
188 match the audio data requirements, and not depend on the default con‐
189 figuration.
190 Recording Audio Data
192 The read() system call copies data from the system's buffers to the
193 application. Ordinarily, read() blocks until the user buffer is filled.
194 The I_NREAD ioctl (see streamio(7I)) may be used to determine the
195 amount of data that may be read without blocking. The device may alter‐
196 natively be set to a non-blocking mode, in which case read() completes
197 immediately, but may return fewer bytes than requested. Refer to the
198 read(2) manual page for a complete description of this behavior.
199 When the audio device is opened with read access, the device driver
202 immediately starts buffering audio input data. Since this consumes sys‐
203 tem resources, processes that do not record audio data should open the
204 device write-only (O_WRONLY).
205 The transfer of input data to STREAMS buffers may be paused (or
208 resumed) by using the AUDIO_SETINFO ioctl to set (or clear) the
209 record.pause flag in the audio information structure (see below). All
210 unread input data in the STREAMS queue may be discarded by using the
211 I_FLUSH STREAMS ioctl. See streamio(7I). When changing record parame‐
212 ters, the input stream should be paused and flushed before the change,
213 and resumed afterward. Otherwise, subsequent reads may return samples
214 in the old format followed by samples in the new format. This is par‐
215 ticularly important when new parameters result in a changed sample
216 size.
217 Input data can accumulate in STREAMS buffers very quickly. At a mini‐
220 mum, it will accumulate at 8000 bytes per second for 8-bit, 8 KHz,
221 mono, u-Law data. If the device is configured for 16-bit linear or
222 higher sample rates, it will accumulate even faster. If the application
223 that consumes the data cannot keep up with this data rate, the STREAMS
224 queue may become full. When this occurs, the record.error flag is set
225 in the audio information structure and input sampling ceases until
226 there is room in the input queue for additional data. In such cases,
227 the input data stream contains a discontinuity. For this reason, audio
228 recording applications should open the audio device when they are pre‐
229 pared to begin reading data, rather than at the start of extensive ini‐
230 tialization.
231 Playing Audio Data
233 The write() system call copies data from an application's buffer to the
234 STREAMS output queue. Ordinarily, write() blocks until the entire user
235 buffer is transferred. The device may alternatively be set to a non-
236 blocking mode, in which case write() completes immediately, but may
237 have transferred fewer bytes than requested. See write(2).
238 Although write() returns when the data is successfully queued, the
241 actual completion of audio output may take considerably longer. The
242 AUDIO_DRAIN ioctl may be issued to allow an application to block until
243 all of the queued output data has been played. Alternatively, a process
244 may request asynchronous notification of output completion by writing a
245 zero-length buffer (end-of-file record) to the output stream. When such
246 a buffer has been processed, the play.eof flag in the audio information
247 structure is incremented.
248 The final close(2) of the file descriptor hangs until all of the audio
251 output has drained. If a signal interrupts the close(), or if the
252 process exits without closing the device, any remaining data queued for
253 audio output is flushed and the device is closed immediately.
254 The consumption of output data may be paused (or resumed) by using the
257 AUDIO_SETINFO ioctl to set (or clear) the play.pause flag in the audio
258 information structure. Queued output data may be discarded by using the
259 I_FLUSH STREAMS ioctl. (See streamio(7I)).
260 Output data is played from the STREAMS buffers at a default rate of at
263 least 8000 bytes per second for μ-Law, A-Law or 8-bit PCM data (faster
264 for 16-bit linear data or higher sampling rates). If the output queue
265 becomes empty, the play.error flag is set in the audio information
266 structure and output is stopped until additional data is written. If an
267 application attempts to write a number of bytes that is not a multiple
268 of the current sample frame size, an error is generated and the bad
269 data is thrown away. Additional writes are allowed.
270 Asynchronous I/O
272 The I_SETSIG STREAMS ioctl enables asynchronous notification, through
273 the SIGPOLL signal, of input and output ready condition changes. The
274 O_NONBLOCK flag may be set using the F_SETFL fcntl(2) to enable non-
275 blocking read() and write() requests. This is normally sufficient for
276 applications to maintain an audio stream in the background.
277 Audio Control Pseudo-Device
279 It is sometimes convenient to have an application, such as a volume
280 control panel, modify certain characteristics of the audio device while
281 it is being used by an unrelated process.
282 The /dev/audioctl pseudo-device is provided for this purpose. Any num‐
285 ber of processes may open /dev/audioctl simultaneously. However, read()
286 and write() system calls are ignored by /dev/audioctl. The AUDIO_GET‐
287 INFO and AUDIO_SETINFO ioctl commands may be issued to /dev/audioctl to
288 determine the status or alter the behavior of /dev/audio. Note: In gen‐
289 eral, the audio control device name is constructed by appending the
290 letters "ctl" to the path name of the audio device.
291 Audio Status Change Notification
293 Applications that open the audio control pseudo-device may request
294 asynchronous notification of changes in the state of the audio device
295 by setting the S_MSG flag in an I_SETSIG STREAMS ioctl. Such processes
296 receive a SIGPOLL signal when any of the following events occur:
297 o An AUDIO_SETINFO ioctl has altered the device state.
299 o An input overflow or output underflow has occurred.
301 o An end-of-file record (zero-length buffer) has been pro‐
303 cessed on output.
304 o An open() or close() of /dev/audio has altered the device
306 state.
307 o An external event (such as speakerbox's volume control) has
309 altered the device state.
310
312 Audio Information Structure
313 The state of the audio device may be polled or modified using the
314 AUDIO_GETINFO and AUDIO_SETINFO ioctl commands. These commands operate
315 on the audio_info structure as defined, in <sys/audio.h>, as follows:
316 /*
318 * This structure contains state information for audio device
319 * IO streams
320 */
321 struct audio_prinfo {
323 /*
324 * The following values describe the
325 * audio data encoding
326 */
327 uint_t sample_rate; /* samples per second */
328 uint_t channels; /* number of interleaved channels */
329 uint_t precision; /* number of bits per sample */
330 uint_t encoding; /* data encoding method */
331 /*
334 * The following values control audio device
335 * configuration
336 */
337 uint_t gain; /* volume level */
338 uint_t port; /* selected I/O port */
339 uint_t buffer_size; /* I/O buffer size */
340 /*
342 * The following values describe the current device
343 * state
344 */
345 uint_t samples; /* number of samples converted */
346 uint_t eof; /* End Of File counter (play only) */
347 uchar_t pause; /* non-zero if paused, zero to resume */
348 uchar_t error; /* non-zero if overflow/underflow */
349 uchar_t waiting; /* non-zero if a process wants access */
350 uchar_t balance; /* stereo channel balance */
351 /*
352 * The following values are read-only device state
353 * information
354 */
355 uchar_t open;/* non-zero if open access granted */
356 uchar_t active; /* non-zero if I/O active */
357 uint_t avail_ports; /* available I/O ports */
358 uint_t mod_ports; /* modifiable I/O ports */
359 };
360 typedef struct audio_prinfo audio_prinfo_t;
361 /*
363 * This structure is used in AUDIO_GETINFO and AUDIO_SETINFO ioctl
364 * commands
365 */
366 struct audio_info {
367 audio_prinfo_t record;/* input status info */
368 audio_prinfo_t play;/* output status info */
369 uint_t monitor_gain; /* input to output mix */
370 uchar_toutput_muted; /* non-zero if output muted */
371 uint_t hw_features; /* supported H/W features */
372 uint_t sw_features;/* supported S/W features */
373 uint_t sw_features_enabled;
374 /* supported S/W features enabled */
375 };
376 typedef struct audio_info audio_info_t;
377 /* Audio encoding types */
379 #define AUDIO_ENCODING_ULAW (1) /* u-Law encoding */
380 #define AUDIO_ENCODING_ALAW (2) /* A-Law encoding */
381 #define AUDIO_ENCODING_LINEAR (3) /* Signed Linear PCM encoding */
382 /*
383 * These ranges apply to record, play, and
384 * monitor gain values
385 */
386 #define AUDIO_MIN_GAIN (0)/* minimum gain value */
387 #define AUDIO_MAX_GAIN (255) /* maximum gain value */
388 /*
390 * These values apply to the balance field to adjust channel
391 * gain values
392 */
393 #define AUDIO_LEFT_BALANCE(0) /* left channel only */
394 #define AUDIO_MID_BALANCE (32) /* equal left/right balance */
395 #define AUDIO_RIGHT_BALANCE (64) /* right channel only */
396 /*
398 * Define some convenient audio port names
399 * (for port, avail_ports and mod_ports)
400 */
401 /* output ports (several might be enabled at once) */
403 #define AUDIO_SPEAKER (0x01)/* built-in speaker */
404 #define AUDIO_HEADPHONE (0x02)/* headphone jack */
405 #define AUDIO_LINE_OUT (0x04)/* line out */
406 #define AUDIO_SPDIF_OUT (0x08)/* SPDIF port */
407 #define AUDIO_AUX1_OUT (0x10)/* aux1 out */
408 #define AUDIO_AUX2_OUT (0x20)/* aux2 out */
409 /* input ports (usually only one may be
411 * enabled at a time)
412 */
413 #define AUDIO_MICROPHONE (0x01) /* microphone */
414 #define AUDIO_LINE_IN (0x02) /* line in */
415 #define AUDIO_CD(0x04) /* on-board CD inputs */
416 #define AUDIO_SPDIF_IN (0x08) /* SPDIF port */
417 #define AUDIO_AUX1_IN (0x10) /* aux1 in */
418 #define AUDIO_AUX2_IN (0x20) /* aux2 in */
419 #define AUDIO_CODEC_LOOPB_IN (0x40) /* Codec inter.loopback */
420 /* These defines are for hardware features */
422 #define AUDIO_HWFEATURE_DUPLEX (0x00000001u)
423 /*simult. play & cap. supported */
424 #define AUDIO_HWFEATURE_MSCODEC (0x00000002u)
426 /* multi-stream Codec */
427 /* These defines are for software features *
429 #define AUDIO_SWFEATURE_MIXER (0x00000001u)
430 /* audio mixer audio pers. mod. */
431 /*
433 * Parameter for the AUDIO_GETDEV ioctl
434 * to determine current audio devices
435 */#define MAX_AUDIO_DEV_LEN(16)
436 struct audio_device {
437 char name[MAX_AUDIO_DEV_LEN];
438 char version[MAX_AUDIO_DEV_LEN];
439 char config[MAX_AUDIO_DEV_LEN];
440 };
441 typedef struct audio_device audio_device_t;
442 The play.gain and record.gain fields specify the output and input vol‐
446 ume levels. A value of AUDIO_MAX_GAIN indicates maximum volume. Audio
447 output may also be temporarily muted by setting a non-zero value in the
448 output_muted field. Clearing this field restores audio output to the
449 normal state.
450 The monitor_gain field is present for compatibility, and is no longer
453 supported. See dsp(7I) for more detail.
454 Likewise, the play.port, play.ports, play.mod_ports, record.port,
457 record.ports, and record.mod_ports are no longer supported. See dsp(7I)
458 for more detail.
459 The play.balance and record.balance fields are fixed to AUDIO_MID_BAL‐
462 ANCE. Changes to volume levels for different channels can be made using
463 the interfaces in dsp(7I).
464 The play.pause and record.pause flags may be used to pause and resume
467 the transfer of data between the audio device and the STREAMS buffers.
468 The play.error and record.error flags indicate that data underflow or
469 overflow has occurred. The play.active and record.active flags indicate
470 that data transfer is currently active in the corresponding direction.
471 The play.open and record.open flags indicate that the device is cur‐
474 rently open with the corresponding access permission. The play.waiting
475 and record.waiting flags provide an indication that a process may be
476 waiting to access the device. These flags are set automatically when a
477 process blocks on open(), though they may also be set using the
478 AUDIO_SETINFO ioctl command. They are cleared only when a process
479 relinquishes access by closing the device.
480 The play.samples and record.samples fields are zeroed at open() and are
483 incremented each time a data sample is copied to or from the associated
484 STREAMS queue. Some audio drivers may be limited to counting buffers of
485 samples, instead of single samples for their samples accounting. For
486 this reason, applications should not assume that the samples fields
487 contain a perfectly accurate count. The play.eof field increments when‐
488 ever a zero-length output buffer is synchronously processed. Applica‐
489 tions may use this field to detect the completion of particular seg‐
490 ments of audio output.
491 The record.buffer_size field controls the amount of input data that is
494 buffered in the device driver during record operations. Applications
495 that have particular requirements for low latency should set the value
496 appropriately. Note however that smaller input buffer sizes may result
497 in higher system overhead. The value of this field is specified in
498 bytes and drivers will constrain it to be a multiple of the current
499 sample frame size. Some drivers may place other requirements on the
500 value of this field. Refer to the audio device-specific manual page
501 for more details. If an application changes the format of the audio
502 device and does not modify the record.buffer_size field, the device
503 driver may use a default value to compensate for the new data rate.
504 Therefore, if an application is going to modify this field, it should
505 modify it during or after the format change itself, not before. When
506 changing the record.buffer_size parameters, the input stream should be
507 paused and flushed before the change, and resumed afterward. Otherwise,
508 subsequent reads may return samples in the old format followed by sam‐
509 ples in the new format. This is particularly important when new parame‐
510 ters result in a changed sample size. If you change the record.buf‐
511 fer_size for the first packet, this protocol must be followed or the
512 first buffer will be the default buffer size for the device, followed
513 by packets of the requested change size.
514 The record.buffer_size field may be modified only on the /dev/audio
517 device by processes that have it opened for reading.
518 The play.buffer_size field is currently not supported.
521 The audio data format is indicated by the sample_rate, channels, preci‐
524 sion and encoding fields. The values of these fields correspond to the
525 descriptions in the AUDIO FORMATS section of this man page. Refer to
526 the audio device-specific manual pages for a list of supported data
527 format combinations.
528 The data format fields can be modified only on the /dev/audio device.
531 If the parameter changes requested by an AUDIO_SETINFO ioctl cannot all
534 be accommodated, ioctl() returns with errno set to EINVAL and no
535 changes are made to the device state.
536 Streamio IOCTLS
538 All of the streamio(7I) ioctl commands may be issued for the /dev/audio
539 device. Because the /dev/audioctl device has its own STREAMS queues,
540 most of these commands neither modify nor report the state of
541 /dev/audio if issued for the /dev/audioctl device. The I_SETSIG ioctl
542 may be issued for /dev/audioctl to enable the notification of audio
543 status changes, as described above.
544 Audio IOCTLS
546 The audio device additionally supports the following ioctl commands:
547 AUDIO_DRAIN The argument is ignored. This command suspends the
549 calling process until the output STREAMS queue is
550 empty and all queued samples have been played, or
551 until a signal is delivered to the calling process. It
552 may not be issued for the /dev/audioctldevice. An
553 implicit AUDIO_DRAIN is performed on the final close()
554 of /dev/audio.
555 AUDIO_GETDEV The argument is a pointer to an audio_device_t struc‐
558 ture. This command may be issued for either /dev/audio
559 or /dev/audioctl. The returned value in the name field
560 will be a string that will identify the current
561 /dev/audio hardware device, the value in version will
562 be a string indicating the current version of the
563 hardware, and config will be a device-specific string
564 identifying the properties of the audio stream associ‐
565 ated with that file descriptor. Refer to the audio
566 device-specific manual pages to determine the actual
567 strings returned by the device driver.
568 AUDIO_GETINFO The argument is a pointer to an audio_info_t struc‐
571 ture. This command may be issued for either /dev/audio
572 or /dev/audioctl. The current state of the /dev/audio
573 device is returned in the structure.
574 Values return pertain to a logical view of the device
576 as seen by and private to the process, and do not nec‐
577 essarily reflect the actual hardware device itself.
578 AUDIO_SETINFO The argument is a pointer to an audio_info_t struc‐
581 ture. This command may be issued for either the
582 /dev/audio or the /dev/audioctl device with some
583 restrictions. This command configures the audio device
584 according to the supplied structure and overwrites the
585 existing structure with the new state of the device.
586 Note: The play.samples, record.samples, play.error,
587 record.error, and play.eof fields are modified to
588 reflect the state of the device when the AUDIO_SETINFO
589 is issued. This allows programs to automatically mod‐
590 ify these fields while retrieving the previous value.
591 As with AUDIO_SETINFO, the settings managed by this
593 ioctl deal with a logical view of the device which is
594 private to the process, and don't necessarily have any
595 impact on the hardware device itself.
596 Certain fields in the audio information structure, such as the pause
600 flags, are treated as read-only when /dev/audio is not open with the
601 corresponding access permission. Other fields, such as the gain levels
602 and encoding information, may have a restricted set of acceptable val‐
603 ues. Applications that attempt to modify such fields should check the
604 returned values to be sure that the corresponding change took effect.
605 The sample_rate, channels, precision, and encoding fields treated as
606 read-only for /dev/audioctl, so that applications can be guaranteed
607 that the existing audio format will stay in place until they relinquish
608 the audio device. AUDIO_SETINFO will return EINVAL when the desired
609 configuration is not possible, or EBUSY when another process has con‐
610 trol of the audio device.
611 All of the logical device state is reset when the corresponding I/O
614 stream of /dev/audio is closed.
615 The audio_info_t structure may be initialized through the use of the
618 AUDIO_INITINFO macro. This macro sets all fields in the structure to
619 values that are ignored by the AUDIO_SETINFO command. For instance, the
620 following code switches the output port from the built-in speaker to
621 the headphone jack without modifying any other audio parameters:
622 audio_info_t info;
624 AUDIO_INITINFO();
625 info.play.port = AUDIO_HEADPHONE;
626 err = ioctl(audio_fd, AUDIO_SETINFO, );
627 This technique eliminates problems associated with using a sequence of
632 AUDIO_GETINFO followed by AUDIO_SETINFO.
633
635 An open() will fail if:
636 EBUSY The requested play or record access is busy and either the
638 O_NDELAY or O_NONBLOCK flag was set in the open() request.
639 EINTR The requested play or record access is busy and a signal
642 interrupted the open() request.
643 An ioctl() will fail if:
647 EINVAL The parameter changes requested in the AUDIO_SETINFO() ioctl
649 are invalid or are not supported by the device.
650
653 The physical audio device names are system dependent and are rarely
654 used by programmers. Programmers should use the following generic
655 device names:
656 /dev/audio Symbolic link to the system's primary audio
658 device
659 /dev/audioctl Symbolic link to the control device for
662 /dev/audio
663 /dev/sound/0 First audio device in the system
666 /dev/sound/0ctl Audio control device for /dev/sound/0
669 /usr/share/audio/samples Audio files
672
675 See attributes(5) for a description of the following attributes:
676 ┌────────────────────┬──────────────────────────────────────┐
681 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
682 ├────────────────────┼──────────────────────────────────────┤
683 │Architecture │SPARC, x86 │
684 ├────────────────────┼──────────────────────────────────────┤
685 │Availability │SUNWcsu, SUNWaudd, SUNWaudh │
686 ├────────────────────┼──────────────────────────────────────┤
687 │Stability Level │Obsolete Uncommitted │
688 └────────────────────┴──────────────────────────────────────┘
689
691 close(2), fcntl(2), ioctl(2), open(2), poll(2), read(2), write(2),
692 attributes(5), dsp(7I), streamio(7I)
693
695 Due to a feature of the STREAMS implementation, programs that are ter‐
696 minated or exit without closing the audio device may hang for a short
697 period while audio output drains. In general, programs that produce
698 audio output should catch the SIGINT signal and flush the output stream
699 before exiting.
700SunOS 5.11 6 May 2009 audio(7I)