Lines Matching refs:the
10 ALSA provides a powerful OSS emulation on the kernel.
13 When you need to access the OSS PCM, mixer or sequencer devices, the
16 These modules are loaded automatically when the corresponding service
18 the card number and the minor unit number. Usually you don't have to
21 Only necessary step for auto-loading of OSS modules is to define the
26 As the second card, define sound-slot-1 as well.
27 Note that you can't use the aliased name as the target name (i.e.
28 "alias sound-slot-0 snd-card-0" doesn't work any more like the old
32 /proc/asound/oss/sndstat. This shows in the same syntax of
33 /dev/sndstat, which is available on the commercial OSS driver.
36 Please note that the devices listed in this proc file appear only
37 after the corresponding OSS-emulation module is loaded. Don't worry
44 ALSA supports the following OSS device files:
61 where X is the card number from 0 to 7.
63 (NOTE: Some distributions have the device files like /dev/midi0 and
67 Unlike the real OSS, ALSA cannot use the device files more than the
68 assigned ones. For example, the first card cannot use /dev/dsp1 or
71 As seen above, PCM and MIDI may have two devices. Usually, the first
72 PCM device (hw:0,0 in ALSA) is mapped to /dev/dsp and the secondary
76 You can change this device mapping via the module options of
77 snd-pcm-oss and snd-rawmidi. In the case of PCM, the following
85 For example, to map the third PCM device (hw:0,2) to /dev/adsp0,
90 The options take arrays. For configuring the second card, specify
91 two entries separated by comma. For example, to map the third PCM
92 device on the second card to /dev/adsp1, define like below:
96 To change the mapping of MIDI devices, the following options are
104 For example, to assign the third MIDI device on the first card to
113 As default, ALSA emulates the OSS PCM with so-called plugin layer,
114 i.e. tries to convert the sample format, rate or channels
115 automatically when the card doesn't support it natively.
117 wine, especially if they use the card only in the MMAP mode.
119 In such a case, you can change the behavior of PCM per application by
120 writing a command to the proc file. There is a proc file for each PCM
121 stream, /proc/asound/cardX/pcmY[cp]/oss, where X is the card number
122 (zero-based), Y the PCM device number (zero-based), and 'p' is for
126 The command sequence has the following syntax:
130 app_name is the name of application with (higher priority) or without
132 fragments specifies the number of fragments or zero if no specific
134 fragment_size is the size of fragment in bytes or zero if not given.
135 options is the optional parameters. The following options are
138 disable the application tries to open a pcm device for
147 capture) is not handled correctly by the application although the
149 The direct option is used, as mentioned above, to bypass the automatic
151 For example, to playback the first PCM device without plugins for
152 quake, send a command via echo like the following:
156 While quake wants only playback, you may append the second command
161 The permission of proc files depend on the module options of snd.
163 sending the command above.
165 The block and non-block options are used to change the behavior of
166 opening the device file.
169 the file when it's busy. The -EBUSY error is returned in this case.
172 module option of snd-pcm-oss. For using the blocking mode as default
173 for OSS devices, define like the following:
179 specifies to invoke the write transfer only when the whole fragment is
180 filled. The latter stops writing the silence data ahead
183 You can check the currently defined configuration by reading the proc
184 file. The read image can be sent to the proc file again, hence you
185 can save the current configuration
193 Also, for clearing all the current configuration, send "erase" command
202 Since ALSA has completely different mixer interface, the emulation of
204 from several different ALSA (mixer) controls based on the name
205 string. For example, the volume element SOUND_MIXER_PCM is composed
206 from "PCM Playback Volume" and "PCM Playback Switch" controls for the
208 Switch" for the capture directory (if exists). When the PCM volume of
209 OSS is changed, all the volume and switch controls above are adjusted
212 As default, ALSA uses the following control for OSS volumes:
242 The second column is the base-string of the corresponding ALSA
243 control. In fact, the controls with "XXX [Playback|Capture]
246 The current assignment of these mixer elements is listed in the proc
247 file, /proc/asound/cardX/oss_mixer, which will be like the following
256 where the first column is the OSS volume element, the second column
257 the base-string of the corresponding ALSA control, and the third the
258 control index. When the string is empty, it means that the
261 For changing the assignment, you can write the configuration to this
262 proc file. For example, to map "Wave Playback" to the PCM volume,
263 send the command like the following:
267 The command is exactly as same as listed in the proc file. You can
268 change one or more elements, one volume per line. In the last
272 Like the case of PCM proc file, the permission of proc files depend on
273 the module options of snd. you'll likely need to be superuser for
274 sending the command above.
276 As well as in the case of PCM proc file, you can save and restore the
277 current mixer configuration by reading and writing the whole file
285 capture, the OSS API provides no way to set the format, sample rate or
288 will only function correctly if the values are the same in each direction.
290 To use different values in the two directions, use both
293 and set the values for the corresponding handle.
301 ICE1712 supports only the unconventional format, interleaved
303 the buffer as the conventional (mono or 2-channels, 8 or 16bit) format