![[Top]](Top.gif)
![[Prev]](Previous.gif)
![[Next]](Next.gif)
bind -a '#A' /dev /dev/audio /dev/audioctl
If the application writes to the audio file faster than the buffer sends it to the output, the application blocks until there is enough internal memory to hold the incoming data.
The microphone input begins at the first read request and ends at close, or until the internal buffers are full. A subsequent read will then start the input again.
The input may end if the read is not fast enough. This may lead to dropped data samples.
The audioctl file settings are persistent across process invocations. An application running on Inferno should query the capabilities of the local audio device before utilizing any audio services. An application should prepare the audio file for output by sending the appropriate message to the audioctl file prior to reading or writing data.
Valid messages written to the audioctl file using the write system call return a non-zero value equal to the length of the ASCII message string. Invalid messages written to the audioctl file using the write system call return a value equal to -1.
Applications reading from the audioctl file should supply a buffer of size AUDIO_INFO_MAX (512). The returned string from reading audioctl contains the supported type strings along with all the acceptable values for that type. The first value following the type is the current value. The returned string can then be tokenized using system calls and processed appropriately.
Messages sent to the audioctl file to control output, block the process until any existing raw data in the audio file has been played. The state of the audio file output processing is then modified so that new raw data written to audio will play appropriately.
Messages sent to the audioctl file to control input result in flushing any unread raw input data in the audio file. The state of the audio file input processing is then modified so that new raw data read from audio will match the new input control settings.
The messages sent to or received from the audioctl file are ASCII-based text messages following the syntax:
[dir] type value [type value1 value2 value3]
The types and their acceptable values are listed as follows:
|
ulaw
|
µ-law encoding
|
|
alaw
|
A-law encoding
|
|
pcm
|
Pulse Code Modulation encoding
|
|
8000
|
8000 samples per second
|
|
11025
|
11025 samples per second
|
|
22050
|
22050 samples per second
|
|
44100
|
44100 samples per second
|
|
1
|
1 channel
|
|
2
|
2 channels
|
|
8
|
8 bits per sample
|
|
16
|
16 bits per sample
|
|
0 - 100
|
Any whole number between 0 and 100 representing the percentage between the minimum and maximum buffering capability.
|
|
0
|
flush in/out.
|
|
#
|
number of samples waiting for I/O
|
|
mic
|
input microphone
|
|
spkr
|
output speaker
|
A write to the audio file means your data has been queued to play but does not mean it has completed playing (sound may linger and continue although your write succeeds).
When your application closes down, the close will block until all queued data has been played on the speakers
To read or write audio data over a network, first cross mount to another machine and then read or write to the other machine.
On Win95 and Win NT, mute your microphone first so you don't hear your echo