diff options
Diffstat (limited to 'Documentation/sound/alsa/OSS-Emulation.txt')
-rw-r--r-- | Documentation/sound/alsa/OSS-Emulation.txt | 297 |
1 files changed, 297 insertions, 0 deletions
diff --git a/Documentation/sound/alsa/OSS-Emulation.txt b/Documentation/sound/alsa/OSS-Emulation.txt new file mode 100644 index 000000000000..ec2a02541d5b --- /dev/null +++ b/Documentation/sound/alsa/OSS-Emulation.txt | |||
@@ -0,0 +1,297 @@ | |||
1 | NOTES ON KERNEL OSS-EMULATION | ||
2 | ============================= | ||
3 | |||
4 | Jan. 22, 2004 Takashi Iwai <tiwai@suse.de> | ||
5 | |||
6 | |||
7 | Modules | ||
8 | ======= | ||
9 | |||
10 | ALSA provides a powerful OSS emulation on the kernel. | ||
11 | The OSS emulation for PCM, mixer and sequencer devices is implemented | ||
12 | as add-on kernel modules, snd-pcm-oss, snd-mixer-oss and snd-seq-oss. | ||
13 | When you need to access the OSS PCM, mixer or sequencer devices, the | ||
14 | corresponding module has to be loaded. | ||
15 | |||
16 | These modules are loaded automatically when the corresponding service | ||
17 | is called. The alias is defined sound-service-x-y, where x and y are | ||
18 | the card number and the minor unit number. Usually you don't have to | ||
19 | define these aliases by yourself. | ||
20 | |||
21 | Only necessary step for auto-loading of OSS modules is to define the | ||
22 | card alias in /etc/modprobe.conf, such as | ||
23 | |||
24 | alias sound-slot-0 snd-emu10k1 | ||
25 | |||
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 | ||
29 | modutils). | ||
30 | |||
31 | The currently available OSS configuration is shown in | ||
32 | /proc/asound/oss/sndstat. This shows in the same syntax of | ||
33 | /dev/sndstat, which is available on the commercial OSS driver. | ||
34 | On ALSA, you can symlink /dev/sndstat to this proc file. | ||
35 | |||
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 | ||
38 | even if "NOT ENABLED IN CONFIG" is shown in it. | ||
39 | |||
40 | |||
41 | Device Mapping | ||
42 | ============== | ||
43 | |||
44 | ALSA supports the following OSS device files: | ||
45 | |||
46 | PCM: | ||
47 | /dev/dspX | ||
48 | /dev/adspX | ||
49 | |||
50 | Mixer: | ||
51 | /dev/mixerX | ||
52 | |||
53 | MIDI: | ||
54 | /dev/midi0X | ||
55 | /dev/amidi0X | ||
56 | |||
57 | Sequencer: | ||
58 | /dev/sequencer | ||
59 | /dev/sequencer2 (aka /dev/music) | ||
60 | |||
61 | where X is the card number from 0 to 7. | ||
62 | |||
63 | (NOTE: Some distributions have the device files like /dev/midi0 and | ||
64 | /dev/midi1. They are NOT for OSS but for tclmidi, which is | ||
65 | a totally different thing.) | ||
66 | |||
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 | ||
69 | /dev/dsp2, but only /dev/dsp0 and /dev/adsp0. | ||
70 | |||
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 | ||
73 | device (hw:0,1) to /dev/adsp (if available). For MIDI, /dev/midi and | ||
74 | /dev/amidi, respectively. | ||
75 | |||
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 | ||
78 | options are available for snd-pcm-oss: | ||
79 | |||
80 | dsp_map PCM device number assigned to /dev/dspX | ||
81 | (default = 0) | ||
82 | adsp_map PCM device number assigned to /dev/adspX | ||
83 | (default = 1) | ||
84 | |||
85 | For example, to map the third PCM device (hw:0,2) to /dev/adsp0, | ||
86 | define like this: | ||
87 | |||
88 | options snd-pcm-oss adsp_map=2 | ||
89 | |||
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: | ||
93 | |||
94 | options snd-pcm-oss adsp_map=0,2 | ||
95 | |||
96 | To change the mapping of MIDI devices, the following options are | ||
97 | available for snd-rawmidi: | ||
98 | |||
99 | midi_map MIDI device number assigned to /dev/midi0X | ||
100 | (default = 0) | ||
101 | amidi_map MIDI device number assigned to /dev/amidi0X | ||
102 | (default = 1) | ||
103 | |||
104 | For example, to assign the third MIDI device on the first card to | ||
105 | /dev/midi00, define as follows: | ||
106 | |||
107 | options snd-rawmidi midi_map=2 | ||
108 | |||
109 | |||
110 | PCM Mode | ||
111 | ======== | ||
112 | |||
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. | ||
116 | This will lead to some problems for some applications like quake or | ||
117 | wine, especially if they use the card only in the MMAP mode. | ||
118 | |||
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 | ||
123 | playback and 'c' for capture, respectively. Note that this proc file | ||
124 | exists only after snd-pcm-oss module is loaded. | ||
125 | |||
126 | The command sequence has the following syntax: | ||
127 | |||
128 | app_name fragments fragment_size [options] | ||
129 | |||
130 | app_name is the name of application with (higher priority) or without | ||
131 | path. | ||
132 | fragments specifies the number of fragments or zero if no specific | ||
133 | number is given. | ||
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 | ||
136 | available: | ||
137 | |||
138 | disable the application tries to open a pcm device for | ||
139 | this channel but does not want to use it. | ||
140 | direct don't use plugins | ||
141 | block force block open mode | ||
142 | non-block force non-block open mode | ||
143 | partial-frag write also partial fragments (affects playback only) | ||
144 | no-silence do not fill silence ahead to avoid clicks | ||
145 | |||
146 | The disable option is useful when one stream direction (playback or | ||
147 | capture) is not handled correctly by the application although the | ||
148 | hardware itself does support both directions. | ||
149 | The direct option is used, as mentioned above, to bypass the automatic | ||
150 | conversion and useful for MMAP-applications. | ||
151 | For example, to playback the first PCM device without plugins for | ||
152 | quake, send a command via echo like the following: | ||
153 | |||
154 | % echo "quake 0 0 direct" > /proc/asound/card0/pcm0p/oss | ||
155 | |||
156 | While quake wants only playback, you may append the second command | ||
157 | to notify driver that only this direction is about to be allocated: | ||
158 | |||
159 | % echo "quake 0 0 disable" > /proc/asound/card0/pcm0c/oss | ||
160 | |||
161 | The permission of proc files depend on the module options of snd. | ||
162 | As default it's set as root, so you'll likely need to be superuser for | ||
163 | sending the command above. | ||
164 | |||
165 | The block and non-block options are used to change the behavior of | ||
166 | opening the device file. | ||
167 | |||
168 | As default, ALSA behaves as original OSS drivers, i.e. does not block | ||
169 | the file when it's busy. The -EBUSY error is returned in this case. | ||
170 | |||
171 | This blocking behavior can be changed globally via nonblock_open | ||
172 | module option of snd-pcm-oss. For using the blocking mode as default | ||
173 | for OSS devices, define like the following: | ||
174 | |||
175 | options snd-pcm-oss nonblock_open=0 | ||
176 | |||
177 | The partial-frag and no-silence commands have been added recently. | ||
178 | Both commands are for optimization use only. The former command | ||
179 | specifies to invoke the write transfer only when the whole fragment is | ||
180 | filled. The latter stops writing the silence data ahead | ||
181 | automatically. Both are disabled as default. | ||
182 | |||
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 | ||
186 | |||
187 | % cat /proc/asound/card0/pcm0p/oss > /somewhere/oss-cfg | ||
188 | |||
189 | and restore it like | ||
190 | |||
191 | % cat /somewhere/oss-cfg > /proc/asound/card0/pcm0p/oss | ||
192 | |||
193 | Also, for clearing all the current configuration, send "erase" command | ||
194 | as below: | ||
195 | |||
196 | % echo "erase" > /proc/asound/card0/pcm0p/oss | ||
197 | |||
198 | |||
199 | Mixer Elements | ||
200 | ============== | ||
201 | |||
202 | Since ALSA has completely different mixer interface, the emulation of | ||
203 | OSS mixer is relatively complicated. ALSA builds up a mixer element | ||
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 | ||
207 | playback direction and from "PCM Capture Volume" and "PCM Capture | ||
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 | ||
210 | automatically. | ||
211 | |||
212 | As default, ALSA uses the following control for OSS volumes: | ||
213 | |||
214 | OSS volume ALSA control Index | ||
215 | ----------------------------------------------------- | ||
216 | SOUND_MIXER_VOLUME Master 0 | ||
217 | SOUND_MIXER_BASS Tone Control - Bass 0 | ||
218 | SOUND_MIXER_TREBLE Tone Control - Treble 0 | ||
219 | SOUND_MIXER_SYNTH Synth 0 | ||
220 | SOUND_MIXER_PCM PCM 0 | ||
221 | SOUND_MIXER_SPEAKER PC Speaker 0 | ||
222 | SOUND_MIXER_LINE Line 0 | ||
223 | SOUND_MIXER_MIC Mic 0 | ||
224 | SOUND_MIXER_CD CD 0 | ||
225 | SOUND_MIXER_IMIX Monitor Mix 0 | ||
226 | SOUND_MIXER_ALTPCM PCM 1 | ||
227 | SOUND_MIXER_RECLEV (not assigned) | ||
228 | SOUND_MIXER_IGAIN Capture 0 | ||
229 | SOUND_MIXER_OGAIN Playback 0 | ||
230 | SOUND_MIXER_LINE1 Aux 0 | ||
231 | SOUND_MIXER_LINE2 Aux 1 | ||
232 | SOUND_MIXER_LINE3 Aux 2 | ||
233 | SOUND_MIXER_DIGITAL1 Digital 0 | ||
234 | SOUND_MIXER_DIGITAL2 Digital 1 | ||
235 | SOUND_MIXER_DIGITAL3 Digital 2 | ||
236 | SOUND_MIXER_PHONEIN Phone 0 | ||
237 | SOUND_MIXER_PHONEOUT Phone 1 | ||
238 | SOUND_MIXER_VIDEO Video 0 | ||
239 | SOUND_MIXER_RADIO Radio 0 | ||
240 | SOUND_MIXER_MONITOR Monitor 0 | ||
241 | |||
242 | The second column is the base-string of the corresponding ALSA | ||
243 | control. In fact, the controls with "XXX [Playback|Capture] | ||
244 | [Volume|Switch]" will be checked in addition. | ||
245 | |||
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 | ||
248 | |||
249 | VOLUME "Master" 0 | ||
250 | BASS "" 0 | ||
251 | TREBLE "" 0 | ||
252 | SYNTH "" 0 | ||
253 | PCM "PCM" 0 | ||
254 | ... | ||
255 | |||
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 | ||
259 | corresponding OSS control is not available. | ||
260 | |||
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: | ||
264 | |||
265 | % echo 'VOLUME "Wave Playback" 0' > /proc/asound/card0/oss_mixer | ||
266 | |||
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 | ||
269 | example, both "Wave Playback Volume" and "Wave Playback Switch" will | ||
270 | be affected when PCM volume is changed. | ||
271 | |||
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. | ||
275 | |||
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 | ||
278 | image. | ||
279 | |||
280 | |||
281 | Unsupported Features | ||
282 | ==================== | ||
283 | |||
284 | MMAP on ICE1712 driver | ||
285 | ---------------------- | ||
286 | ICE1712 supports only the unconventional format, interleaved | ||
287 | 10-channels 24bit (packed in 32bit) format. Therefore you cannot mmap | ||
288 | the buffer as the conventional (mono or 2-channels, 8 or 16bit) format | ||
289 | on OSS. | ||
290 | |||
291 | USB devices | ||
292 | ----------- | ||
293 | Some USB devices support only 24bit format packed in 3bytes. This | ||
294 | format is not supported by OSS and no conversion is provided by kernel | ||
295 | OSS emulation. You can use the user-space OSS emulation via libaoss | ||
296 | instead. | ||
297 | |||