diff options
author | Takashi Iwai <tiwai@suse.de> | 2008-12-03 12:26:35 -0500 |
---|---|---|
committer | Takashi Iwai <tiwai@suse.de> | 2008-12-03 12:26:35 -0500 |
commit | a7fe49bf01dd64b3c73ad0e172f68bd03c813d65 (patch) | |
tree | 925a1491e5dc33ff1ef10792713edb54a85030a7 /Documentation/sound/alsa/HD-Audio.txt | |
parent | 061e41fdb5047b1fb161e89664057835935ca1d2 (diff) |
ALSA: Add more documentation about HD-audio driver
The file can be converted to PDF via asciidoc.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'Documentation/sound/alsa/HD-Audio.txt')
-rw-r--r-- | Documentation/sound/alsa/HD-Audio.txt | 535 |
1 files changed, 535 insertions, 0 deletions
diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt new file mode 100644 index 000000000000..e758f24017bf --- /dev/null +++ b/Documentation/sound/alsa/HD-Audio.txt | |||
@@ -0,0 +1,535 @@ | |||
1 | MORE NOTES ON HD-AUDIO DRIVER | ||
2 | ============================= | ||
3 | Takashi Iwai <tiwai@suse.de> | ||
4 | |||
5 | |||
6 | GENERAL | ||
7 | ------- | ||
8 | |||
9 | HD-audio is the new standard on-board audio component on modern PCs | ||
10 | after AC97. Although Linux has been supporting HD-audio since long | ||
11 | time ago, there are often problems with new machines. A part of the | ||
12 | problem is broken BIOS, and rest is the driver implementation. This | ||
13 | document explains the trouble-shooting and debugging methods for the | ||
14 | HD-audio hardware. | ||
15 | |||
16 | The HD-audio component consists of two parts: the controller chip and | ||
17 | the codec chips on the HD-audio bus. Linux provides a single driver | ||
18 | for all controllers, snd-hda-intel. Since the HD-audio controllers | ||
19 | are supposed to be compatible, the single snd-hda-driver should work | ||
20 | in most cases. But, not surprisingly, there are known bugs and issues | ||
21 | specific to each controller type. The snd-hda-intel driver has a | ||
22 | bunch of workarounds for these as described below. | ||
23 | |||
24 | A controller may have multiple codecs. Usually you have one audio | ||
25 | codec and optionally one modem codec. In some cases, there can be | ||
26 | multiple audio codecs, e.g. for analog and digital outputs, but the | ||
27 | driver might not work properly. | ||
28 | |||
29 | The snd-hda-intel driver has several different codec parsers depending | ||
30 | on the codec. It has a generic parser as a fallback, but this | ||
31 | functionality is fairly limited until now. Instead of the generic | ||
32 | parser, usually the codec-specific parser (coded in patch_*.c) is used | ||
33 | for the codec-specific implementations. The details about the | ||
34 | codec-specific problems are explained in the later sections. | ||
35 | |||
36 | If you are interested in the deep debugging of HD-audio, read the | ||
37 | HD-audio specification at first. The specification is found on | ||
38 | Intel's web page, for example: | ||
39 | |||
40 | - http://www.intel.com/standards/hdaudio/ | ||
41 | |||
42 | |||
43 | HD-AUDIO CONTROLLER | ||
44 | ------------------- | ||
45 | |||
46 | DMA-Position Problem | ||
47 | ~~~~~~~~~~~~~~~~~~~~ | ||
48 | The most common problem of the controller is the inaccurate DMA | ||
49 | pointer reporting. The DMA pointer for playback and capture can be | ||
50 | read in two ways, either via a LPIB register or via a position-buffer | ||
51 | map. As default the driver tries to reads from the io-mapped | ||
52 | position-buffer, and falls back to LPIB if it appears unupdated. | ||
53 | However, this detection isn't perfect on some devices. In such a | ||
54 | case, you can change the default method via `position_fix` option. | ||
55 | |||
56 | `position_fix=1` means to use LPIB method explicitly. | ||
57 | `position_fix=2` means to use the position-buffer. 0 is the default | ||
58 | value, the automatic check. If you get a problem of repeated sounds, | ||
59 | this option might help. | ||
60 | |||
61 | In addition to that, every controller is known to be broken regarding | ||
62 | the wake-up timing. It wakes up a few samples before actually | ||
63 | processing the data on the buffer. This caused a lot of problems, for | ||
64 | example, with ALSA dmix or JACK. Since 2.6.27 kernel, the driver puts | ||
65 | an artificial delay to the wake up timing. This delay is controlled | ||
66 | via `bdl_pos_adj` option. | ||
67 | |||
68 | When `bdl_pos_adj` is a negative value (as default), it's assigned to | ||
69 | an appropriate value depending on the controller chip. For Intel | ||
70 | chip, it'd be 1 while it'd be 32 for others. Usually this works. | ||
71 | Only in case it doesn't work and you get warning messages, you should | ||
72 | change to other values. | ||
73 | |||
74 | |||
75 | Codec-Probing Problem | ||
76 | ~~~~~~~~~~~~~~~~~~~~~ | ||
77 | A less often but a more severe problem is the codec probing. When | ||
78 | BIOS reports the available codec slots wrongly, the driver gets | ||
79 | confused and tries to access the non-existing codec slot. This often | ||
80 | results in the total screw-up, and destruct the further communication | ||
81 | with the codec chips. The symptom appears usually as the error | ||
82 | message like: | ||
83 | ------------------------------------------------------------------------ | ||
84 | hda_intel: azx_get_response timeout, switching to polling mode: \ | ||
85 | last cmd=0x12345678 | ||
86 | hda_intel: azx_get_response timeout, switching to single_cmd mode: \ | ||
87 | last cmd=0x12345678 | ||
88 | ------------------------------------------------------------------------ | ||
89 | |||
90 | The first line is a warning, and this is usually relatively harmless. | ||
91 | It means that the codec response isn't notified via an IRQ. The | ||
92 | driver uses explicit polling method to read the response. It gives | ||
93 | very slight CPU overhead, but you'd unlikely notice it. | ||
94 | |||
95 | The second line is, however, a fatal error. If this happens, usually | ||
96 | it means that something is really wrong. Most likely you are | ||
97 | accessing a non-existing codec slot. | ||
98 | |||
99 | Thus, if the second error message appears, try to narrow the probed | ||
100 | codec slots via `probe_mask` option. It's a bitmask, and each bit | ||
101 | corresponding to the codec slot. For example, to probe only the | ||
102 | first slot, pass `probe_mask=1`. For the first and the third slots, | ||
103 | pass `probe_mask=5` (where 5 = 1 | 4), and so on. | ||
104 | |||
105 | Since 2.6.29 kernel, the driver has a more robust probing method, so | ||
106 | this error might happen rarely, though. | ||
107 | |||
108 | |||
109 | Interrupt Handling | ||
110 | ~~~~~~~~~~~~~~~~~~ | ||
111 | In rare but some cases, the interrupt isn't properly handled as | ||
112 | default. You would notice this by the DMA transfer error reported by | ||
113 | ALSA PCM core, for example. Using MSI might help in such a case. | ||
114 | Pass `enable_msi=1` option for enabling MSI. | ||
115 | |||
116 | |||
117 | HD-AUDIO CODEC | ||
118 | -------------- | ||
119 | |||
120 | Model Option | ||
121 | ~~~~~~~~~~~~ | ||
122 | The most common problems with the HD-audio driver is the unsupported | ||
123 | codec features or the mismatched device configuration. Most of | ||
124 | codec-specific code has several preset models, either to override the | ||
125 | BIOS setup or to provide more comprehensive features. | ||
126 | |||
127 | The driver checks PCI SSID and looks through the static configuration | ||
128 | table until any matching entry is found. If you have a new machine, | ||
129 | you may see a message like below: | ||
130 | ------------------------------------------------------------------------ | ||
131 | hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... | ||
132 | ------------------------------------------------------------------------ | ||
133 | Even if you such a message, DON'T PANIC. Take a deep breath (and keep | ||
134 | your towel). First of all, it's an informational message, no warning, | ||
135 | no error. This means that the PCI SSID of your device isn't listed in | ||
136 | the known preset model list. But, this doesn't mean that the driver | ||
137 | is broken. Many codec-driver provides the automatic configuration | ||
138 | based on the BIOS setup. | ||
139 | |||
140 | The HD-audio codec has usually "pin" widgets, and BIOS sets the default | ||
141 | configuration of each pin, which indicates the location, the | ||
142 | connection type, the jack color, etc. The HD-audio driver can guess | ||
143 | the right connection judging from these default configuration values. | ||
144 | However -- some codec support codes, such as patch_analog.c, don't | ||
145 | support the automatic probing (yet as of 2.6.28). And, BIOS is often, | ||
146 | yes, pretty often broken. It sets up wrong values and screws up the | ||
147 | driver. | ||
148 | |||
149 | The preset model is provided basically to override such a situation. | ||
150 | When the matching preset model is found in the list, the driver | ||
151 | assumes the static configuration of that preset and builds the mixer | ||
152 | and PCM based on the static information. Thus, if you have a newer | ||
153 | machine with a slightly different PCI SSID from the existing one, you | ||
154 | may have a good chance to re-use the same model. You can pass the | ||
155 | `model` option to specify the preset model instead of PCI SSID | ||
156 | look-up. | ||
157 | |||
158 | What `model` option values are available depends on the codec chip. | ||
159 | Check your codec chip from the codec proc file (see "Codec Proc-File" | ||
160 | section below). It will show the vendor/product name of your codec | ||
161 | chip. Then, see Documentation/sound/alsa/ALSA-Configuration.txt file. | ||
162 | In the section of HD-audio driver, you can find a list of codecs and | ||
163 | `model` options belonging to each codec. For example, for Realtek | ||
164 | ALC262 codec chip, pass `model=ultra` for devices that are compatible | ||
165 | with Samsung Q1 Ultra. | ||
166 | |||
167 | Thus, the first thing you can do for any brand-new, unsupported | ||
168 | HD-audio hardware is to check HD-audio codec and several different | ||
169 | `model` option values. If you have a luck, some of them might suit | ||
170 | with your device well. | ||
171 | |||
172 | Some codecs such as ALC880 have a special model option `model=test`. | ||
173 | This configures the driver to provide as many mixer controls as | ||
174 | possible for every single pin feature except for the unsolicited | ||
175 | events (and maybe some other specials). Adjust each mixer element and | ||
176 | try the I/O in the way of trial-and-error until figuring out the whole | ||
177 | I/O pin mappings. | ||
178 | |||
179 | Note that `model=generic` has a special meaning. It means to use the | ||
180 | generic parser regardless of the codec. Usually the codec-specific | ||
181 | parser is much better than the generic parser (as now). Thus this | ||
182 | option is more about the debugging purpose. | ||
183 | |||
184 | |||
185 | Speaker and Headphone Output | ||
186 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
187 | One of the most frequent (and obvious) bugs with HD-audio is the | ||
188 | silent output from either or both of a built-in speaker and a | ||
189 | headphone jack. In general, you should try a headphone output at | ||
190 | first. A speaker output often requires more additional controls like | ||
191 | the amplifier. Thus a headphone output has a slightly better chance. | ||
192 | |||
193 | Before making a bug report, double-check whether the mixer is set up | ||
194 | correctly. The recent version of snd-hda-intel driver provides mostly | ||
195 | "Master" volume control as well as "Front" volume. In addition, there | ||
196 | are individual "Headphone" and "Speaker" controls. | ||
197 | |||
198 | Ditto for the speaker output. There can be "External Amplifier" | ||
199 | switch on some codecs. Turn on this if present. | ||
200 | |||
201 | Another related problem is the automatic mute of speaker output by | ||
202 | headphone plugging. This feature is implemented in most cases, but | ||
203 | not on every preset model or codec-support code. | ||
204 | |||
205 | In anyway, try a different model option if you have such a problem. | ||
206 | Some other models may match better and give you more matching | ||
207 | functionality. If none of the available models works, send a bug | ||
208 | report. See the bug report section for details. | ||
209 | |||
210 | If you are masochistic enough to debug the driver problem, note the | ||
211 | following: | ||
212 | |||
213 | - The speaker (and the headphone, too) output often requires the | ||
214 | external amplifier. This can be set usually via EAPD verb or a | ||
215 | certain GPIO. If the codec pin supports EAPD, you have a better | ||
216 | chance via SET_EAPD_BTL verb (0x70c). On others, GPIO pin (mostly | ||
217 | it's either GPIO0 or GPIO1) can turn on/off EAPD. | ||
218 | - Some Realtek codecs require special vendor-specific coefficients to | ||
219 | turn on the amplifier. See patch_realtek.c. | ||
220 | - IDT codecs may have extra power-enable/disable controls on each | ||
221 | analog pin. See patch_sigmatel.c. | ||
222 | - Very rare but some devices don't accept the pin-detection verb until | ||
223 | triggered. Issuing GET_PIN_SENSE verb (0xf09) may result in the | ||
224 | codec-communication stall. Some examples are found in | ||
225 | patch_realtek.c. | ||
226 | |||
227 | |||
228 | Capture Problems | ||
229 | ~~~~~~~~~~~~~~~~ | ||
230 | The capture problems are often missing setups of mixers. Thus, before | ||
231 | submitting a bug report, make sure that you set up the mixer | ||
232 | correctly. For example, both "Capture Volume" and "Capture Switch" | ||
233 | have to be set properly in addition to the right "Capture Source" or | ||
234 | "Input Source" selection. Some devices have "Mic Boost" volume or | ||
235 | switch. | ||
236 | |||
237 | When the PCM device is opened via "default" PCM (without pulse-audio | ||
238 | plugin), you'll likely have "Digital Capture Volume" control as well. | ||
239 | This is provided for the extra gain/attenuation of the signal in | ||
240 | software, especially for the inputs without the hardware volume | ||
241 | control such as digital microphones. Unless really needed, this | ||
242 | should be set to exactly 50%, corresponding to 0dB. When you use "hw" | ||
243 | PCM, i.e., a raw access PCM, this control will have no influence, | ||
244 | though. | ||
245 | |||
246 | It's known that some codecs / devices have fairly bad analog circuits, | ||
247 | and the recorded sound contains a certain DC-offset. This is no bug | ||
248 | of the driver. | ||
249 | |||
250 | Most of modern laptops have no analog CD-input connection. Thus, the | ||
251 | recording from CD input won't work in many cases although the driver | ||
252 | provides it as the capture source. | ||
253 | |||
254 | The automatic switching of the built-in and external mic per plugging | ||
255 | is implemented on some codec models but not on every model. Partly | ||
256 | because of my laziness but mostly lack of testers. Feel free to | ||
257 | submit the improvement patch to the author. | ||
258 | |||
259 | |||
260 | Direct Debugging | ||
261 | ~~~~~~~~~~~~~~~~ | ||
262 | If no model option gives you a better result, and you are a touch guy | ||
263 | to fight again the evil, try debugging via hitting the raw HD-audio | ||
264 | codec verbs to the device. Some tools are available: hda-emu and | ||
265 | hda-analyzer. The detailed description is found in the sections | ||
266 | below. You'd need to enable hwdep for using these tools. See "Kernel | ||
267 | Configuration". | ||
268 | |||
269 | |||
270 | OTHER ISSUES | ||
271 | ------------ | ||
272 | |||
273 | Kernel Configuration | ||
274 | ~~~~~~~~~~~~~~~~~~~~ | ||
275 | In general, I recommend you to enable the sound debug option, | ||
276 | `CONFIG_SND_DEBUG=y`, no matter whether you are debugging or not. | ||
277 | This enables snd_printd() macro and others, and you'll get additional | ||
278 | kernel messages at probing. | ||
279 | |||
280 | In addition, you can enable `CONFIG_SND_DEBUG_VERBOSE=y`. But this | ||
281 | will give you far more messages. Thus turn this on only when you are | ||
282 | sure to want it. | ||
283 | |||
284 | Don't forget to turn on the appropriate `CONFIG_SND_HDA_CODEC_*` | ||
285 | options. Note that each of them corresponds to the codec chip, not | ||
286 | the controller chip. Thus, even if lspci shows the Nvidia controller, | ||
287 | you may choose the option for other vendors. If you are unsure, just | ||
288 | choose all yes. | ||
289 | |||
290 | `CONFIG_SND_HDA_HWDEP` is a useful option for debugging the driver. | ||
291 | When this is enabled, the driver creates hardware-dependent devices | ||
292 | (one per each codec), and you have a raw access to the device via | ||
293 | hda-verb program. For example, `hwC0D2` will be created for the card | ||
294 | 0 codec slot #2. For debug tools such as hda-verb and hda-analyzer, | ||
295 | the hwdep device has to be enabled. Thus, turn this on always. | ||
296 | |||
297 | `CONFIG_SND_HDA_RECONFIG` is a new option, and this depends on the | ||
298 | hwdep option above. When enabled, you'll have some sysfs files under | ||
299 | the corresponding hwdep directory. See "HD-audio reconfiguration" | ||
300 | section below. | ||
301 | |||
302 | `CONFIG_SND_HDA_POWER_SAVE` option enables the power-saving feature. | ||
303 | See "Power-saving" section below. | ||
304 | |||
305 | |||
306 | Codec Proc-File | ||
307 | ~~~~~~~~~~~~~~~ | ||
308 | The codec proc-file is a treasure-chest for debugging HD-audio. | ||
309 | It shows most of useful information of each codec widget. | ||
310 | |||
311 | The proc file is located in /proc/asound/card*/codec#*, one file per | ||
312 | each codec slot. You can know the codec vendor, product id and | ||
313 | names, the type of each widget, capabilities and so on. | ||
314 | This file, however, doesn't show the jack sensing state, so far. This | ||
315 | is because the jack-sensing might be depending on the trigger state. | ||
316 | |||
317 | This file will be picked up by the debug tools, and also it can be fed | ||
318 | to the emulator as the primary codec information. See the debug tools | ||
319 | section below. | ||
320 | |||
321 | This proc file can be also used to check whether the generic parser is | ||
322 | used. When the generic parser is used, the vendor/product ID name | ||
323 | will appear as "Realtek ID 0262", instead of "Realtek ALC262". | ||
324 | |||
325 | |||
326 | HD-Audio Reconfiguration | ||
327 | ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
328 | This is an experimental feature to allow you re-configure the HD-audio | ||
329 | codec dynamically without reloading the driver. The following sysfs | ||
330 | files are available under each codec-hwdep device directory (e.g. | ||
331 | /sys/class/sound/hwC0D0): | ||
332 | |||
333 | vendor_id:: | ||
334 | Shows the 32bit codec vendor-id hex number. You can change the | ||
335 | vendor-id value by writing to this file. | ||
336 | subsystem_id:: | ||
337 | Shows the 32bit codec subsystem-id hex number. You can change the | ||
338 | subsystem-id value by writing to this file. | ||
339 | revision_id:: | ||
340 | Shows the 32bit codec revision-id hex number. You can change the | ||
341 | revision-id value by writing to this file. | ||
342 | afg:: | ||
343 | Shows the AFG ID. This is read-only. | ||
344 | mfg:: | ||
345 | Shows the MFG ID. This is read-only. | ||
346 | name:: | ||
347 | Shows the codec name string. Can be changed by writing to this | ||
348 | file. | ||
349 | modelname:: | ||
350 | Shows the currently set `model` option. Can be changed by writing | ||
351 | to this file. | ||
352 | init_verbs:: | ||
353 | The extra verbs to execute at initialization. You can add a verb by | ||
354 | writing to this file. Pass tree numbers, nid, verb and parameter. | ||
355 | hints:: | ||
356 | Shows hint strings for codec parsers for any use. Right now it's | ||
357 | not used. | ||
358 | reconfig:: | ||
359 | Triggers the codec re-configuration. When any value is written to | ||
360 | this file, the driver re-initialize and parses the codec tree | ||
361 | again. All the changes done by the sysfs entries above are taken | ||
362 | into account. | ||
363 | clear:: | ||
364 | Resets the codec, removes the mixer elements and PCM stuff of the | ||
365 | specified codec, and clear all init verbs and hints. | ||
366 | |||
367 | |||
368 | Power-Saving | ||
369 | ~~~~~~~~~~~~ | ||
370 | The power-saving is a kind of auto-suspend of the device. When the | ||
371 | device is inactive for a certain time, the device is automatically | ||
372 | turned off to save the power. The time to go down is specified via | ||
373 | `power_save` module option, and this option can be changed dynamically | ||
374 | via sysfs. | ||
375 | |||
376 | The power-saving won't work when the analog loopback is enabled on | ||
377 | some codecs. Make sure that you mute all unneeded signal routes when | ||
378 | you want the power-saving. | ||
379 | |||
380 | The power-saving feature might cause audible click noises at each | ||
381 | power-down/up depending on the device. Some of them might be | ||
382 | solvable, but some are hard, I'm afraid. Some distros such as | ||
383 | openSUSE enables the power-saving feature automatically when the power | ||
384 | cable is unplugged. Thus, if you hear noises, suspect first the | ||
385 | power-saving. See /sys/modules/snd_hda_intel/parameters/power_save to | ||
386 | check the current value. If it's non-zero, the feature is turned on. | ||
387 | |||
388 | |||
389 | Sending a Bug Report | ||
390 | ~~~~~~~~~~~~~~~~~~~~ | ||
391 | If any model or module options don't work for your device, it's time | ||
392 | to send a bug report to the developers. Give the following in your | ||
393 | bug report: | ||
394 | |||
395 | - Hardware vendor, product and model names | ||
396 | - Kernel version (and ALSA-driver version if you built externally) | ||
397 | - `alsa-info.sh` output; run with `--no-upload` option. See the | ||
398 | section below about alsa-info | ||
399 | |||
400 | If it's a regression, at best, send alsa-info outputs of both working | ||
401 | and non-working kernels. This is really helpful because we can | ||
402 | compare the codec registers directly. | ||
403 | |||
404 | Send a bug report either the followings: | ||
405 | |||
406 | kernel-bugzilla:: | ||
407 | http://bugme.linux-foundation.org/ | ||
408 | alsa-devel ML:: | ||
409 | alsa-devel@alsa-project.org | ||
410 | |||
411 | |||
412 | DEBUG TOOLS | ||
413 | ----------- | ||
414 | |||
415 | This section describes some tools available for debugging HD-audio | ||
416 | problems. | ||
417 | |||
418 | alsa-info | ||
419 | ~~~~~~~~~ | ||
420 | The script `alsa-info.sh` is a very useful tool to gather the audio | ||
421 | device information. You can fetch the latest version from: | ||
422 | |||
423 | - http://www.alsa-project.org/alsa-info.sh | ||
424 | |||
425 | Run this script as root, and it will gather the important information | ||
426 | such as the module lists, module parameters, proc file contents | ||
427 | including the codec proc files, mixer outputs and the control | ||
428 | elements. As default, it will store the information onto a web server | ||
429 | on alsa-project.org. But, if you send a bug report, it'd be better to | ||
430 | run with `--no-upload` option, and attach the generated file. | ||
431 | |||
432 | There are some other useful options. See `--help` option output for | ||
433 | details. | ||
434 | |||
435 | |||
436 | hda-verb | ||
437 | ~~~~~~~~ | ||
438 | hda-verb is a tiny program that allows you to access the HD-audio | ||
439 | codec directly. It executes a HD-audio codec verb directly. | ||
440 | This program accesses the hwdep device, thus you need to enable the | ||
441 | kernel config `CONFIG_SND_HDA_HWDEP=y` beforehand. | ||
442 | |||
443 | The hda-verb program takes four arguments: the hwdep device file, the | ||
444 | widget NID, the verb and the parameter. When you access to the codec | ||
445 | on the slot 2 of the card 0, pass /dev/snd/hwC0D2 to the first | ||
446 | argument, typically. (However, the real path name depends on the | ||
447 | system.) | ||
448 | |||
449 | The second parameter is the widget number-id to access. The third | ||
450 | parameter can be either a hex/digit number or a string corresponding | ||
451 | to a verb. Similarly, the last parameter is the value to write, or | ||
452 | can be a string for the parameter type. | ||
453 | |||
454 | ------------------------------------------------------------------------ | ||
455 | % hda-verb /dev/snd/hwC0D0 0x12 0x701 2 | ||
456 | nid = 0x12, verb = 0x701, param = 0x2 | ||
457 | value = 0x0 | ||
458 | |||
459 | % hda-verb /dev/snd/hwC0D0 0x0 PARAMETERS VENDOR_ID | ||
460 | nid = 0x0, verb = 0xf00, param = 0x0 | ||
461 | value = 0x10ec0262 | ||
462 | |||
463 | % hda-verb /dev/snd/hwC0D0 2 set_a 0xb080 | ||
464 | nid = 0x2, verb = 0x300, param = 0xb080 | ||
465 | value = 0x0 | ||
466 | ------------------------------------------------------------------------ | ||
467 | |||
468 | Although you can issue any verbs with this program, the driver state | ||
469 | won't be always updated. For example, the volume values are usually | ||
470 | cached in the driver, and thus changing the widget amp value directly | ||
471 | via hda-verb won't change the mixer value. | ||
472 | |||
473 | The hda-verb program is found in the ftp directory: | ||
474 | |||
475 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ | ||
476 | |||
477 | Also a git repository is available: | ||
478 | |||
479 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-verb.git | ||
480 | |||
481 | See README file in the tarball for more details about hda-verb | ||
482 | program. | ||
483 | |||
484 | |||
485 | hda-analyzer | ||
486 | ~~~~~~~~~~~~ | ||
487 | hda-analyzer provides a graphical interface to access the raw HD-audio | ||
488 | control, based on pyGTK2 binding. It's a more powerful version of | ||
489 | hda-verb. The program gives you a easy-to-use GUI stuff for showing | ||
490 | the widget information and adjusting the amp values, as well as the | ||
491 | proc-compatible output. | ||
492 | |||
493 | The hda-analyzer is a part of alsa.git repository in | ||
494 | alsa-project.org: | ||
495 | |||
496 | - http://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer | ||
497 | |||
498 | |||
499 | hda-emu | ||
500 | ~~~~~~~ | ||
501 | hda-emu is a HD-audio emulator. The main purpose of this program is | ||
502 | to debug an HD-audio codec without the real hardware. Thus, it | ||
503 | doesn't emulate the behavior with the real audio I/O, but it just | ||
504 | dumps the codec register changes and the ALSA-driver internal changes | ||
505 | at probing and operating the HD-audio driver. | ||
506 | |||
507 | The program requires a codec proc-file to simulate. Get a proc file | ||
508 | for the target codec beforehand, or pick up an example codec from the | ||
509 | codec proc collections in the tarball. Then, run the program with the | ||
510 | proc file, and the hda-emu program will start parsing the codec file | ||
511 | and simulates the HD-audio driver: | ||
512 | |||
513 | ------------------------------------------------------------------------ | ||
514 | % hda-emu codecs/stac9200-dell-d820-laptop | ||
515 | # Parsing.. | ||
516 | hda_codec: Unknown model for STAC9200, using BIOS defaults | ||
517 | hda_codec: pin nid 08 bios pin config 40c003fa | ||
518 | .... | ||
519 | ------------------------------------------------------------------------ | ||
520 | |||
521 | The program gives you only a very dumb command-line interface. You | ||
522 | can get a proc-file dump at the current state, get a list of control | ||
523 | (mixer) elements, set/get the control element value, simulate the PCM | ||
524 | operation, the jack plugging simulation, etc. | ||
525 | |||
526 | The package is found in: | ||
527 | |||
528 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ | ||
529 | |||
530 | A git repository is available: | ||
531 | |||
532 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git | ||
533 | |||
534 | See README file in the tarball for more details about hda-emu | ||
535 | program. | ||