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 | ~~~~~~~~~~~~~~~~~~ | |
91cb1731 TI |
122 | HD-audio driver uses MSI as default (if available) since 2.6.33 |
123 | kernel as MSI works better on some machines, and in general, it's | |
124 | better for performance. However, Nvidia controllers showed bad | |
125 | regressions with MSI (especially in a combination with AMD chipset), | |
126 | thus we disabled MSI for them. | |
127 | ||
128 | There seem also still other devices that don't work with MSI. If you | |
129 | see a regression wrt the sound quality (stuttering, etc) or a lock-up | |
130 | in the recent kernel, try to pass `enable_msi=0` option to disable | |
131 | MSI. If it works, you can add the known bad device to the blacklist | |
132 | defined in hda_intel.c. In such a case, please report and give the | |
133 | patch back to the upstream developer. | |
a7fe49bf TI |
134 | |
135 | ||
136 | HD-AUDIO CODEC | |
137 | -------------- | |
138 | ||
139 | Model Option | |
140 | ~~~~~~~~~~~~ | |
d2afbe78 TI |
141 | The most common problem regarding the HD-audio driver is the |
142 | unsupported codec features or the mismatched device configuration. | |
143 | Most of codec-specific code has several preset models, either to | |
144 | override the BIOS setup or to provide more comprehensive features. | |
a7fe49bf TI |
145 | |
146 | The driver checks PCI SSID and looks through the static configuration | |
147 | table until any matching entry is found. If you have a new machine, | |
148 | you may see a message like below: | |
9a11f1aa TI |
149 | ------------------------------------------------------------------------ |
150 | hda_codec: ALC880: BIOS auto-probing. | |
151 | ------------------------------------------------------------------------ | |
152 | Meanwhile, in the earlier versions, you would see a message like: | |
a7fe49bf TI |
153 | ------------------------------------------------------------------------ |
154 | hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... | |
155 | ------------------------------------------------------------------------ | |
d2afbe78 TI |
156 | Even if you see such a message, DON'T PANIC. Take a deep breath and |
157 | keep your towel. First of all, it's an informational message, no | |
158 | warning, no error. This means that the PCI SSID of your device isn't | |
159 | listed in the known preset model (white-)list. But, this doesn't mean | |
160 | that the driver is broken. Many codec-drivers provide the automatic | |
161 | configuration mechanism based on the BIOS setup. | |
a7fe49bf TI |
162 | |
163 | The HD-audio codec has usually "pin" widgets, and BIOS sets the default | |
164 | configuration of each pin, which indicates the location, the | |
165 | connection type, the jack color, etc. The HD-audio driver can guess | |
166 | the right connection judging from these default configuration values. | |
d2afbe78 | 167 | However -- some codec-support codes, such as patch_analog.c, don't |
a7fe49bf TI |
168 | support the automatic probing (yet as of 2.6.28). And, BIOS is often, |
169 | yes, pretty often broken. It sets up wrong values and screws up the | |
170 | driver. | |
171 | ||
d2afbe78 TI |
172 | The preset model is provided basically to overcome such a situation. |
173 | When the matching preset model is found in the white-list, the driver | |
a7fe49bf | 174 | assumes the static configuration of that preset and builds the mixer |
d2afbe78 TI |
175 | elements and PCM streams based on the static information. Thus, if |
176 | you have a newer machine with a slightly different PCI SSID from the | |
177 | existing one, you may have a good chance to re-use the same model. | |
178 | You can pass the `model` option to specify the preset model instead of | |
179 | PCI SSID look-up. | |
a7fe49bf TI |
180 | |
181 | What `model` option values are available depends on the codec chip. | |
182 | Check your codec chip from the codec proc file (see "Codec Proc-File" | |
183 | section below). It will show the vendor/product name of your codec | |
83b2086c | 184 | chip. Then, see Documentation/sound/alsa/HD-Audio-Models.txt file, |
692f9042 | 185 | the section of HD-audio driver. You can find a list of codecs |
d2afbe78 | 186 | and `model` options belonging to each codec. For example, for Realtek |
a7fe49bf TI |
187 | ALC262 codec chip, pass `model=ultra` for devices that are compatible |
188 | with Samsung Q1 Ultra. | |
189 | ||
d2afbe78 TI |
190 | Thus, the first thing you can do for any brand-new, unsupported and |
191 | non-working HD-audio hardware is to check HD-audio codec and several | |
83b2086c | 192 | different `model` option values. If you have any luck, some of them |
d2afbe78 | 193 | might suit with your device well. |
a7fe49bf TI |
194 | |
195 | Some codecs such as ALC880 have a special model option `model=test`. | |
196 | This configures the driver to provide as many mixer controls as | |
197 | possible for every single pin feature except for the unsolicited | |
198 | events (and maybe some other specials). Adjust each mixer element and | |
199 | try the I/O in the way of trial-and-error until figuring out the whole | |
200 | I/O pin mappings. | |
201 | ||
202 | Note that `model=generic` has a special meaning. It means to use the | |
203 | generic parser regardless of the codec. Usually the codec-specific | |
204 | parser is much better than the generic parser (as now). Thus this | |
205 | option is more about the debugging purpose. | |
206 | ||
a7fe49bf TI |
207 | Speaker and Headphone Output |
208 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
209 | One of the most frequent (and obvious) bugs with HD-audio is the | |
210 | silent output from either or both of a built-in speaker and a | |
211 | headphone jack. In general, you should try a headphone output at | |
212 | first. A speaker output often requires more additional controls like | |
d2afbe78 TI |
213 | the external amplifier bits. Thus a headphone output has a slightly |
214 | better chance. | |
a7fe49bf TI |
215 | |
216 | Before making a bug report, double-check whether the mixer is set up | |
217 | correctly. The recent version of snd-hda-intel driver provides mostly | |
d2afbe78 TI |
218 | "Master" volume control as well as "Front" volume (where Front |
219 | indicates the front-channels). In addition, there can be individual | |
220 | "Headphone" and "Speaker" controls. | |
a7fe49bf TI |
221 | |
222 | Ditto for the speaker output. There can be "External Amplifier" | |
223 | switch on some codecs. Turn on this if present. | |
224 | ||
225 | Another related problem is the automatic mute of speaker output by | |
226 | headphone plugging. This feature is implemented in most cases, but | |
227 | not on every preset model or codec-support code. | |
228 | ||
229 | In anyway, try a different model option if you have such a problem. | |
230 | Some other models may match better and give you more matching | |
231 | functionality. If none of the available models works, send a bug | |
232 | report. See the bug report section for details. | |
233 | ||
234 | If you are masochistic enough to debug the driver problem, note the | |
235 | following: | |
236 | ||
237 | - The speaker (and the headphone, too) output often requires the | |
238 | external amplifier. This can be set usually via EAPD verb or a | |
239 | certain GPIO. If the codec pin supports EAPD, you have a better | |
240 | chance via SET_EAPD_BTL verb (0x70c). On others, GPIO pin (mostly | |
d2afbe78 | 241 | it's either GPIO0 or GPIO1) may turn on/off EAPD. |
a7fe49bf TI |
242 | - Some Realtek codecs require special vendor-specific coefficients to |
243 | turn on the amplifier. See patch_realtek.c. | |
244 | - IDT codecs may have extra power-enable/disable controls on each | |
245 | analog pin. See patch_sigmatel.c. | |
246 | - Very rare but some devices don't accept the pin-detection verb until | |
247 | triggered. Issuing GET_PIN_SENSE verb (0xf09) may result in the | |
248 | codec-communication stall. Some examples are found in | |
249 | patch_realtek.c. | |
250 | ||
251 | ||
252 | Capture Problems | |
253 | ~~~~~~~~~~~~~~~~ | |
d2afbe78 TI |
254 | The capture problems are often because of missing setups of mixers. |
255 | Thus, before submitting a bug report, make sure that you set up the | |
256 | mixer correctly. For example, both "Capture Volume" and "Capture | |
257 | Switch" have to be set properly in addition to the right "Capture | |
258 | Source" or "Input Source" selection. Some devices have "Mic Boost" | |
259 | volume or switch. | |
a7fe49bf TI |
260 | |
261 | When the PCM device is opened via "default" PCM (without pulse-audio | |
262 | plugin), you'll likely have "Digital Capture Volume" control as well. | |
263 | This is provided for the extra gain/attenuation of the signal in | |
264 | software, especially for the inputs without the hardware volume | |
265 | control such as digital microphones. Unless really needed, this | |
d2afbe78 TI |
266 | should be set to exactly 50%, corresponding to 0dB -- neither extra |
267 | gain nor attenuation. When you use "hw" PCM, i.e., a raw access PCM, | |
268 | this control will have no influence, though. | |
a7fe49bf TI |
269 | |
270 | It's known that some codecs / devices have fairly bad analog circuits, | |
271 | and the recorded sound contains a certain DC-offset. This is no bug | |
272 | of the driver. | |
273 | ||
d2afbe78 | 274 | Most of modern laptops have no analog CD-input connection. Thus, the |
a7fe49bf | 275 | recording from CD input won't work in many cases although the driver |
d2afbe78 | 276 | provides it as the capture source. Use CDDA instead. |
a7fe49bf TI |
277 | |
278 | The automatic switching of the built-in and external mic per plugging | |
279 | is implemented on some codec models but not on every model. Partly | |
280 | because of my laziness but mostly lack of testers. Feel free to | |
281 | submit the improvement patch to the author. | |
282 | ||
283 | ||
284 | Direct Debugging | |
285 | ~~~~~~~~~~~~~~~~ | |
f8bbd06b | 286 | If no model option gives you a better result, and you are a tough guy |
623b9f67 | 287 | to fight against evil, try debugging via hitting the raw HD-audio |
a7fe49bf TI |
288 | codec verbs to the device. Some tools are available: hda-emu and |
289 | hda-analyzer. The detailed description is found in the sections | |
290 | below. You'd need to enable hwdep for using these tools. See "Kernel | |
d2afbe78 | 291 | Configuration" section. |
a7fe49bf TI |
292 | |
293 | ||
294 | OTHER ISSUES | |
295 | ------------ | |
296 | ||
297 | Kernel Configuration | |
298 | ~~~~~~~~~~~~~~~~~~~~ | |
299 | In general, I recommend you to enable the sound debug option, | |
300 | `CONFIG_SND_DEBUG=y`, no matter whether you are debugging or not. | |
301 | This enables snd_printd() macro and others, and you'll get additional | |
302 | kernel messages at probing. | |
303 | ||
304 | In addition, you can enable `CONFIG_SND_DEBUG_VERBOSE=y`. But this | |
305 | will give you far more messages. Thus turn this on only when you are | |
306 | sure to want it. | |
307 | ||
308 | Don't forget to turn on the appropriate `CONFIG_SND_HDA_CODEC_*` | |
309 | options. Note that each of them corresponds to the codec chip, not | |
310 | the controller chip. Thus, even if lspci shows the Nvidia controller, | |
d2afbe78 TI |
311 | you may need to choose the option for other vendors. If you are |
312 | unsure, just select all yes. | |
a7fe49bf TI |
313 | |
314 | `CONFIG_SND_HDA_HWDEP` is a useful option for debugging the driver. | |
315 | When this is enabled, the driver creates hardware-dependent devices | |
316 | (one per each codec), and you have a raw access to the device via | |
d2afbe78 TI |
317 | these device files. For example, `hwC0D2` will be created for the |
318 | codec slot #2 of the first card (#0). For debug-tools such as | |
319 | hda-verb and hda-analyzer, the hwdep device has to be enabled. | |
320 | Thus, it'd be better to turn this on always. | |
a7fe49bf TI |
321 | |
322 | `CONFIG_SND_HDA_RECONFIG` is a new option, and this depends on the | |
323 | hwdep option above. When enabled, you'll have some sysfs files under | |
324 | the corresponding hwdep directory. See "HD-audio reconfiguration" | |
325 | section below. | |
326 | ||
327 | `CONFIG_SND_HDA_POWER_SAVE` option enables the power-saving feature. | |
328 | See "Power-saving" section below. | |
329 | ||
330 | ||
331 | Codec Proc-File | |
332 | ~~~~~~~~~~~~~~~ | |
333 | The codec proc-file is a treasure-chest for debugging HD-audio. | |
334 | It shows most of useful information of each codec widget. | |
335 | ||
336 | The proc file is located in /proc/asound/card*/codec#*, one file per | |
337 | each codec slot. You can know the codec vendor, product id and | |
338 | names, the type of each widget, capabilities and so on. | |
339 | This file, however, doesn't show the jack sensing state, so far. This | |
340 | is because the jack-sensing might be depending on the trigger state. | |
341 | ||
342 | This file will be picked up by the debug tools, and also it can be fed | |
343 | to the emulator as the primary codec information. See the debug tools | |
344 | section below. | |
345 | ||
346 | This proc file can be also used to check whether the generic parser is | |
347 | used. When the generic parser is used, the vendor/product ID name | |
348 | will appear as "Realtek ID 0262", instead of "Realtek ALC262". | |
349 | ||
350 | ||
351 | HD-Audio Reconfiguration | |
352 | ~~~~~~~~~~~~~~~~~~~~~~~~ | |
353 | This is an experimental feature to allow you re-configure the HD-audio | |
354 | codec dynamically without reloading the driver. The following sysfs | |
355 | files are available under each codec-hwdep device directory (e.g. | |
356 | /sys/class/sound/hwC0D0): | |
357 | ||
358 | vendor_id:: | |
359 | Shows the 32bit codec vendor-id hex number. You can change the | |
360 | vendor-id value by writing to this file. | |
361 | subsystem_id:: | |
362 | Shows the 32bit codec subsystem-id hex number. You can change the | |
363 | subsystem-id value by writing to this file. | |
364 | revision_id:: | |
365 | Shows the 32bit codec revision-id hex number. You can change the | |
366 | revision-id value by writing to this file. | |
367 | afg:: | |
368 | Shows the AFG ID. This is read-only. | |
369 | mfg:: | |
370 | Shows the MFG ID. This is read-only. | |
371 | name:: | |
372 | Shows the codec name string. Can be changed by writing to this | |
373 | file. | |
374 | modelname:: | |
375 | Shows the currently set `model` option. Can be changed by writing | |
376 | to this file. | |
377 | init_verbs:: | |
378 | The extra verbs to execute at initialization. You can add a verb by | |
d02b1f39 TI |
379 | writing to this file. Pass three numbers: nid, verb and parameter |
380 | (separated with a space). | |
a7fe49bf | 381 | hints:: |
d02b1f39 TI |
382 | Shows / stores hint strings for codec parsers for any use. |
383 | Its format is `key = value`. For example, passing `hp_detect = yes` | |
384 | to IDT/STAC codec parser will result in the disablement of the | |
385 | headphone detection. | |
f1085c4f TI |
386 | init_pin_configs:: |
387 | Shows the initial pin default config values set by BIOS. | |
346ff70f | 388 | driver_pin_configs:: |
f1085c4f TI |
389 | Shows the pin default values set by the codec parser explicitly. |
390 | This doesn't show all pin values but only the changed values by | |
391 | the parser. That is, if the parser doesn't change the pin default | |
392 | config values by itself, this will contain nothing. | |
346ff70f TI |
393 | user_pin_configs:: |
394 | Shows the pin default config values to override the BIOS setup. | |
395 | Writing this (with two numbers, NID and value) appends the new | |
396 | value. The given will be used instead of the initial BIOS value at | |
5e7b8e0d TI |
397 | the next reconfiguration time. Note that this config will override |
398 | even the driver pin configs, too. | |
a7fe49bf TI |
399 | reconfig:: |
400 | Triggers the codec re-configuration. When any value is written to | |
401 | this file, the driver re-initialize and parses the codec tree | |
402 | again. All the changes done by the sysfs entries above are taken | |
403 | into account. | |
404 | clear:: | |
405 | Resets the codec, removes the mixer elements and PCM stuff of the | |
406 | specified codec, and clear all init verbs and hints. | |
407 | ||
39c2871e TI |
408 | For example, when you want to change the pin default configuration |
409 | value of the pin widget 0x14 to 0x9993013f, and let the driver | |
410 | re-configure based on that state, run like below: | |
411 | ------------------------------------------------------------------------ | |
412 | # echo 0x14 0x9993013f > /sys/class/sound/hwC0D0/user_pin_configs | |
413 | # echo 1 > /sys/class/sound/hwC0D0/reconfig | |
414 | ------------------------------------------------------------------------ | |
415 | ||
a7fe49bf | 416 | |
76824825 TI |
417 | Early Patching |
418 | ~~~~~~~~~~~~~~ | |
419 | When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a | |
420 | firmware file for modifying the HD-audio setup before initializing the | |
421 | codec. This can work basically like the reconfiguration via sysfs in | |
422 | the above, but it does it before the first codec configuration. | |
423 | ||
1e7b8c87 | 424 | A patch file is a plain text file which looks like below: |
76824825 TI |
425 | |
426 | ------------------------------------------------------------------------ | |
427 | [codec] | |
428 | 0x12345678 0xabcd1234 2 | |
429 | ||
430 | [model] | |
431 | auto | |
432 | ||
433 | [pincfg] | |
434 | 0x12 0x411111f0 | |
435 | ||
436 | [verb] | |
437 | 0x20 0x500 0x03 | |
438 | 0x20 0x400 0xff | |
439 | ||
440 | [hint] | |
441 | hp_detect = yes | |
442 | ------------------------------------------------------------------------ | |
443 | ||
444 | The file needs to have a line `[codec]`. The next line should contain | |
445 | three numbers indicating the codec vendor-id (0x12345678 in the | |
446 | example), the codec subsystem-id (0xabcd1234) and the address (2) of | |
447 | the codec. The rest patch entries are applied to this specified codec | |
448 | until another codec entry is given. | |
449 | ||
450 | The `[model]` line allows to change the model name of the each codec. | |
451 | In the example above, it will be changed to model=auto. | |
452 | Note that this overrides the module option. | |
453 | ||
454 | After the `[pincfg]` line, the contents are parsed as the initial | |
455 | default pin-configurations just like `user_pin_configs` sysfs above. | |
456 | The values can be shown in user_pin_configs sysfs file, too. | |
457 | ||
458 | Similarly, the lines after `[verb]` are parsed as `init_verbs` | |
459 | sysfs entries, and the lines after `[hint]` are parsed as `hints` | |
460 | sysfs entries, respectively. | |
461 | ||
b09f3e78 TI |
462 | Another example to override the codec vendor id from 0x12345678 to |
463 | 0xdeadbeef is like below: | |
464 | ------------------------------------------------------------------------ | |
465 | [codec] | |
466 | 0x12345678 0xabcd1234 2 | |
467 | ||
468 | [vendor_id] | |
469 | 0xdeadbeef | |
470 | ------------------------------------------------------------------------ | |
471 | ||
472 | In the similar way, you can override the codec subsystem_id via | |
473 | `[subsystem_id]`, the revision id via `[revision_id]` line. | |
474 | Also, the codec chip name can be rewritten via `[chip_name]` line. | |
475 | ------------------------------------------------------------------------ | |
476 | [codec] | |
477 | 0x12345678 0xabcd1234 2 | |
478 | ||
479 | [subsystem_id] | |
480 | 0xffff1111 | |
481 | ||
482 | [revision_id] | |
483 | 0x10 | |
484 | ||
485 | [chip_name] | |
486 | My-own NEWS-0002 | |
487 | ------------------------------------------------------------------------ | |
488 | ||
1e7b8c87 TI |
489 | The hd-audio driver reads the file via request_firmware(). Thus, |
490 | a patch file has to be located on the appropriate firmware path, | |
491 | typically, /lib/firmware. For example, when you pass the option | |
492 | `patch=hda-init.fw`, the file /lib/firmware/hda-init-fw must be | |
493 | present. | |
494 | ||
495 | The patch module option is specific to each card instance, and you | |
496 | need to give one file name for each instance, separated by commas. | |
497 | For example, if you have two cards, one for an on-board analog and one | |
498 | for an HDMI video board, you may pass patch option like below: | |
499 | ------------------------------------------------------------------------ | |
500 | options snd-hda-intel patch=on-board-patch,hdmi-patch | |
501 | ------------------------------------------------------------------------ | |
502 | ||
76824825 | 503 | |
a7fe49bf TI |
504 | Power-Saving |
505 | ~~~~~~~~~~~~ | |
506 | The power-saving is a kind of auto-suspend of the device. When the | |
507 | device is inactive for a certain time, the device is automatically | |
508 | turned off to save the power. The time to go down is specified via | |
509 | `power_save` module option, and this option can be changed dynamically | |
510 | via sysfs. | |
511 | ||
512 | The power-saving won't work when the analog loopback is enabled on | |
513 | some codecs. Make sure that you mute all unneeded signal routes when | |
514 | you want the power-saving. | |
515 | ||
516 | The power-saving feature might cause audible click noises at each | |
517 | power-down/up depending on the device. Some of them might be | |
518 | solvable, but some are hard, I'm afraid. Some distros such as | |
519 | openSUSE enables the power-saving feature automatically when the power | |
520 | cable is unplugged. Thus, if you hear noises, suspect first the | |
623b9f67 | 521 | power-saving. See /sys/module/snd_hda_intel/parameters/power_save to |
a7fe49bf TI |
522 | check the current value. If it's non-zero, the feature is turned on. |
523 | ||
524 | ||
132bb7c0 TI |
525 | Development Tree |
526 | ~~~~~~~~~~~~~~~~ | |
527 | The latest development codes for HD-audio are found on sound git tree: | |
528 | ||
529 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git | |
530 | ||
531 | The master branch or for-next branches can be used as the main | |
532 | development branches in general while the HD-audio specific patches | |
533 | are committed in topic/hda branch. | |
534 | ||
535 | If you are using the latest Linus tree, it'd be better to pull the | |
536 | above GIT tree onto it. If you are using the older kernels, an easy | |
537 | way to try the latest ALSA code is to build from the snapshot | |
538 | tarball. There are daily tarballs and the latest snapshot tarball. | |
539 | All can be built just like normal alsa-driver release packages, that | |
540 | is, installed via the usual spells: configure, make and make | |
541 | install(-modules). See INSTALL in the package. The snapshot tarballs | |
542 | are found at: | |
543 | ||
544 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ | |
545 | ||
546 | ||
a7fe49bf TI |
547 | Sending a Bug Report |
548 | ~~~~~~~~~~~~~~~~~~~~ | |
549 | If any model or module options don't work for your device, it's time | |
550 | to send a bug report to the developers. Give the following in your | |
551 | bug report: | |
552 | ||
553 | - Hardware vendor, product and model names | |
554 | - Kernel version (and ALSA-driver version if you built externally) | |
555 | - `alsa-info.sh` output; run with `--no-upload` option. See the | |
556 | section below about alsa-info | |
557 | ||
558 | If it's a regression, at best, send alsa-info outputs of both working | |
559 | and non-working kernels. This is really helpful because we can | |
560 | compare the codec registers directly. | |
561 | ||
562 | Send a bug report either the followings: | |
563 | ||
564 | kernel-bugzilla:: | |
0ea6e611 | 565 | https://bugzilla.kernel.org/ |
a7fe49bf TI |
566 | alsa-devel ML:: |
567 | alsa-devel@alsa-project.org | |
568 | ||
569 | ||
570 | DEBUG TOOLS | |
571 | ----------- | |
572 | ||
573 | This section describes some tools available for debugging HD-audio | |
574 | problems. | |
575 | ||
576 | alsa-info | |
577 | ~~~~~~~~~ | |
578 | The script `alsa-info.sh` is a very useful tool to gather the audio | |
579 | device information. You can fetch the latest version from: | |
580 | ||
581 | - http://www.alsa-project.org/alsa-info.sh | |
582 | ||
583 | Run this script as root, and it will gather the important information | |
584 | such as the module lists, module parameters, proc file contents | |
585 | including the codec proc files, mixer outputs and the control | |
586 | elements. As default, it will store the information onto a web server | |
587 | on alsa-project.org. But, if you send a bug report, it'd be better to | |
588 | run with `--no-upload` option, and attach the generated file. | |
589 | ||
590 | There are some other useful options. See `--help` option output for | |
591 | details. | |
592 | ||
ae374d66 TI |
593 | When a probe error occurs or when the driver obviously assigns a |
594 | mismatched model, it'd be helpful to load the driver with | |
595 | `probe_only=1` option (at best after the cold reboot) and run | |
596 | alsa-info at this state. With this option, the driver won't configure | |
597 | the mixer and PCM but just tries to probe the codec slot. After | |
598 | probing, the proc file is available, so you can get the raw codec | |
599 | information before modified by the driver. Of course, the driver | |
600 | isn't usable with `probe_only=1`. But you can continue the | |
601 | configuration via hwdep sysfs file if hda-reconfig option is enabled. | |
10e77dda JK |
602 | Using `probe_only` mask 2 skips the reset of HDA codecs (use |
603 | `probe_only=3` as module option). The hwdep interface can be used | |
604 | to determine the BIOS codec initialization. | |
ae374d66 | 605 | |
a7fe49bf TI |
606 | |
607 | hda-verb | |
608 | ~~~~~~~~ | |
609 | hda-verb is a tiny program that allows you to access the HD-audio | |
d2afbe78 | 610 | codec directly. You can execute a raw HD-audio codec verb with this. |
a7fe49bf TI |
611 | This program accesses the hwdep device, thus you need to enable the |
612 | kernel config `CONFIG_SND_HDA_HWDEP=y` beforehand. | |
613 | ||
614 | The hda-verb program takes four arguments: the hwdep device file, the | |
615 | widget NID, the verb and the parameter. When you access to the codec | |
616 | on the slot 2 of the card 0, pass /dev/snd/hwC0D2 to the first | |
617 | argument, typically. (However, the real path name depends on the | |
618 | system.) | |
619 | ||
620 | The second parameter is the widget number-id to access. The third | |
621 | parameter can be either a hex/digit number or a string corresponding | |
622 | to a verb. Similarly, the last parameter is the value to write, or | |
623 | can be a string for the parameter type. | |
624 | ||
625 | ------------------------------------------------------------------------ | |
626 | % hda-verb /dev/snd/hwC0D0 0x12 0x701 2 | |
627 | nid = 0x12, verb = 0x701, param = 0x2 | |
628 | value = 0x0 | |
629 | ||
630 | % hda-verb /dev/snd/hwC0D0 0x0 PARAMETERS VENDOR_ID | |
631 | nid = 0x0, verb = 0xf00, param = 0x0 | |
632 | value = 0x10ec0262 | |
633 | ||
634 | % hda-verb /dev/snd/hwC0D0 2 set_a 0xb080 | |
635 | nid = 0x2, verb = 0x300, param = 0xb080 | |
636 | value = 0x0 | |
637 | ------------------------------------------------------------------------ | |
638 | ||
639 | Although you can issue any verbs with this program, the driver state | |
640 | won't be always updated. For example, the volume values are usually | |
641 | cached in the driver, and thus changing the widget amp value directly | |
642 | via hda-verb won't change the mixer value. | |
643 | ||
644 | The hda-verb program is found in the ftp directory: | |
645 | ||
646 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ | |
647 | ||
648 | Also a git repository is available: | |
649 | ||
650 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-verb.git | |
651 | ||
652 | See README file in the tarball for more details about hda-verb | |
653 | program. | |
654 | ||
655 | ||
656 | hda-analyzer | |
657 | ~~~~~~~~~~~~ | |
658 | hda-analyzer provides a graphical interface to access the raw HD-audio | |
659 | control, based on pyGTK2 binding. It's a more powerful version of | |
d2afbe78 | 660 | hda-verb. The program gives you an easy-to-use GUI stuff for showing |
a7fe49bf TI |
661 | the widget information and adjusting the amp values, as well as the |
662 | proc-compatible output. | |
663 | ||
11caa3bf | 664 | The hda-analyzer: |
a7fe49bf TI |
665 | |
666 | - http://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer | |
667 | ||
11caa3bf AF |
668 | is a part of alsa.git repository in alsa-project.org: |
669 | ||
670 | - git://git.alsa-project.org/alsa.git | |
a7fe49bf | 671 | |
623b9f67 TI |
672 | Codecgraph |
673 | ~~~~~~~~~~ | |
674 | Codecgraph is a utility program to generate a graph and visualizes the | |
675 | codec-node connection of a codec chip. It's especially useful when | |
676 | you analyze or debug a codec without a proper datasheet. The program | |
677 | parses the given codec proc file and converts to SVG via graphiz | |
678 | program. | |
679 | ||
680 | The tarball and GIT trees are found in the web page at: | |
681 | ||
682 | - http://helllabs.org/codecgraph/ | |
683 | ||
684 | ||
a7fe49bf TI |
685 | hda-emu |
686 | ~~~~~~~ | |
d2afbe78 | 687 | hda-emu is an HD-audio emulator. The main purpose of this program is |
a7fe49bf TI |
688 | to debug an HD-audio codec without the real hardware. Thus, it |
689 | doesn't emulate the behavior with the real audio I/O, but it just | |
690 | dumps the codec register changes and the ALSA-driver internal changes | |
691 | at probing and operating the HD-audio driver. | |
692 | ||
693 | The program requires a codec proc-file to simulate. Get a proc file | |
694 | for the target codec beforehand, or pick up an example codec from the | |
695 | codec proc collections in the tarball. Then, run the program with the | |
696 | proc file, and the hda-emu program will start parsing the codec file | |
697 | and simulates the HD-audio driver: | |
698 | ||
699 | ------------------------------------------------------------------------ | |
700 | % hda-emu codecs/stac9200-dell-d820-laptop | |
701 | # Parsing.. | |
702 | hda_codec: Unknown model for STAC9200, using BIOS defaults | |
703 | hda_codec: pin nid 08 bios pin config 40c003fa | |
704 | .... | |
705 | ------------------------------------------------------------------------ | |
706 | ||
707 | The program gives you only a very dumb command-line interface. You | |
708 | can get a proc-file dump at the current state, get a list of control | |
709 | (mixer) elements, set/get the control element value, simulate the PCM | |
710 | operation, the jack plugging simulation, etc. | |
711 | ||
712 | The package is found in: | |
713 | ||
714 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ | |
715 | ||
716 | A git repository is available: | |
717 | ||
718 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git | |
719 | ||
720 | See README file in the tarball for more details about hda-emu | |
721 | program. |