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