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. | |
4cb36310 DH |
60 | `position_fix=2` means to use the position-buffer. |
61 | `position_fix=3` means to use a combination of both methods, needed | |
a6f2fd55 TI |
62 | for some VIA controllers. The capture stream position is corrected |
63 | by comparing both LPIB and position-buffer values. | |
64 | `position_fix=4` is another combination available for all controllers, | |
65 | and uses LPIB for the playback and the position-buffer for the capture | |
66 | streams. | |
67 | 0 is the default value for all other | |
4cb36310 DH |
68 | controllers, the automatic check and fallback to LPIB as described in |
69 | the above. If you get a problem of repeated sounds, this option might | |
d2afbe78 | 70 | help. |
a7fe49bf TI |
71 | |
72 | In addition to that, every controller is known to be broken regarding | |
73 | the wake-up timing. It wakes up a few samples before actually | |
74 | processing the data on the buffer. This caused a lot of problems, for | |
75 | example, with ALSA dmix or JACK. Since 2.6.27 kernel, the driver puts | |
76 | an artificial delay to the wake up timing. This delay is controlled | |
77 | via `bdl_pos_adj` option. | |
78 | ||
79 | When `bdl_pos_adj` is a negative value (as default), it's assigned to | |
80 | an appropriate value depending on the controller chip. For Intel | |
d2afbe78 | 81 | chips, it'd be 1 while it'd be 32 for others. Usually this works. |
a7fe49bf | 82 | Only in case it doesn't work and you get warning messages, you should |
d2afbe78 | 83 | change this parameter to other values. |
a7fe49bf TI |
84 | |
85 | ||
86 | Codec-Probing Problem | |
87 | ~~~~~~~~~~~~~~~~~~~~~ | |
88 | A less often but a more severe problem is the codec probing. When | |
89 | BIOS reports the available codec slots wrongly, the driver gets | |
90 | confused and tries to access the non-existing codec slot. This often | |
d2afbe78 TI |
91 | results in the total screw-up, and destructs the further communication |
92 | with the codec chips. The symptom appears usually as error messages | |
93 | like: | |
a7fe49bf | 94 | ------------------------------------------------------------------------ |
d2afbe78 | 95 | hda_intel: azx_get_response timeout, switching to polling mode: |
a7fe49bf | 96 | last cmd=0x12345678 |
d2afbe78 | 97 | hda_intel: azx_get_response timeout, switching to single_cmd mode: |
a7fe49bf TI |
98 | last cmd=0x12345678 |
99 | ------------------------------------------------------------------------ | |
100 | ||
101 | The first line is a warning, and this is usually relatively harmless. | |
102 | It means that the codec response isn't notified via an IRQ. The | |
103 | driver uses explicit polling method to read the response. It gives | |
104 | very slight CPU overhead, but you'd unlikely notice it. | |
105 | ||
106 | The second line is, however, a fatal error. If this happens, usually | |
107 | it means that something is really wrong. Most likely you are | |
108 | accessing a non-existing codec slot. | |
109 | ||
110 | Thus, if the second error message appears, try to narrow the probed | |
111 | codec slots via `probe_mask` option. It's a bitmask, and each bit | |
d2afbe78 TI |
112 | corresponds to the codec slot. For example, to probe only the first |
113 | slot, pass `probe_mask=1`. For the first and the third slots, pass | |
114 | `probe_mask=5` (where 5 = 1 | 4), and so on. | |
a7fe49bf TI |
115 | |
116 | Since 2.6.29 kernel, the driver has a more robust probing method, so | |
117 | this error might happen rarely, though. | |
118 | ||
ae374d66 TI |
119 | On a machine with a broken BIOS, sometimes you need to force the |
120 | driver to probe the codec slots the hardware doesn't report for use. | |
121 | In such a case, turn the bit 8 (0x100) of `probe_mask` option on. | |
122 | Then the rest 8 bits are passed as the codec slots to probe | |
123 | unconditionally. For example, `probe_mask=0x103` will force to probe | |
124 | the codec slots 0 and 1 no matter what the hardware reports. | |
125 | ||
a7fe49bf TI |
126 | |
127 | Interrupt Handling | |
128 | ~~~~~~~~~~~~~~~~~~ | |
91cb1731 TI |
129 | HD-audio driver uses MSI as default (if available) since 2.6.33 |
130 | kernel as MSI works better on some machines, and in general, it's | |
131 | better for performance. However, Nvidia controllers showed bad | |
132 | regressions with MSI (especially in a combination with AMD chipset), | |
133 | thus we disabled MSI for them. | |
134 | ||
135 | There seem also still other devices that don't work with MSI. If you | |
136 | see a regression wrt the sound quality (stuttering, etc) or a lock-up | |
137 | in the recent kernel, try to pass `enable_msi=0` option to disable | |
138 | MSI. If it works, you can add the known bad device to the blacklist | |
139 | defined in hda_intel.c. In such a case, please report and give the | |
140 | patch back to the upstream developer. | |
a7fe49bf TI |
141 | |
142 | ||
143 | HD-AUDIO CODEC | |
144 | -------------- | |
145 | ||
146 | Model Option | |
147 | ~~~~~~~~~~~~ | |
d2afbe78 TI |
148 | The most common problem regarding the HD-audio driver is the |
149 | unsupported codec features or the mismatched device configuration. | |
150 | Most of codec-specific code has several preset models, either to | |
151 | override the BIOS setup or to provide more comprehensive features. | |
a7fe49bf TI |
152 | |
153 | The driver checks PCI SSID and looks through the static configuration | |
154 | table until any matching entry is found. If you have a new machine, | |
155 | you may see a message like below: | |
9a11f1aa TI |
156 | ------------------------------------------------------------------------ |
157 | hda_codec: ALC880: BIOS auto-probing. | |
158 | ------------------------------------------------------------------------ | |
159 | Meanwhile, in the earlier versions, you would see a message like: | |
a7fe49bf TI |
160 | ------------------------------------------------------------------------ |
161 | hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... | |
162 | ------------------------------------------------------------------------ | |
d2afbe78 TI |
163 | Even if you see such a message, DON'T PANIC. Take a deep breath and |
164 | keep your towel. First of all, it's an informational message, no | |
165 | warning, no error. This means that the PCI SSID of your device isn't | |
166 | listed in the known preset model (white-)list. But, this doesn't mean | |
167 | that the driver is broken. Many codec-drivers provide the automatic | |
168 | configuration mechanism based on the BIOS setup. | |
a7fe49bf TI |
169 | |
170 | The HD-audio codec has usually "pin" widgets, and BIOS sets the default | |
171 | configuration of each pin, which indicates the location, the | |
172 | connection type, the jack color, etc. The HD-audio driver can guess | |
173 | the right connection judging from these default configuration values. | |
d2afbe78 | 174 | However -- some codec-support codes, such as patch_analog.c, don't |
a7fe49bf TI |
175 | support the automatic probing (yet as of 2.6.28). And, BIOS is often, |
176 | yes, pretty often broken. It sets up wrong values and screws up the | |
177 | driver. | |
178 | ||
7b2ee291 TI |
179 | The preset model (or recently called as "fix-up") is provided |
180 | basically to overcome such a situation. When the matching preset | |
181 | model is found in the white-list, the driver assumes the static | |
182 | configuration of that preset with the correct pin setup, etc. | |
183 | Thus, if you have a newer machine with a slightly different PCI SSID | |
184 | (or codec SSID) from the existing one, you may have a good chance to | |
185 | re-use the same model. You can pass the `model` option to specify the | |
186 | preset model instead of PCI (and codec-) SSID look-up. | |
a7fe49bf TI |
187 | |
188 | What `model` option values are available depends on the codec chip. | |
189 | Check your codec chip from the codec proc file (see "Codec Proc-File" | |
190 | section below). It will show the vendor/product name of your codec | |
83b2086c | 191 | chip. Then, see Documentation/sound/alsa/HD-Audio-Models.txt file, |
692f9042 | 192 | the section of HD-audio driver. You can find a list of codecs |
d2afbe78 | 193 | and `model` options belonging to each codec. For example, for Realtek |
a7fe49bf TI |
194 | ALC262 codec chip, pass `model=ultra` for devices that are compatible |
195 | with Samsung Q1 Ultra. | |
196 | ||
d2afbe78 TI |
197 | Thus, the first thing you can do for any brand-new, unsupported and |
198 | non-working HD-audio hardware is to check HD-audio codec and several | |
83b2086c | 199 | different `model` option values. If you have any luck, some of them |
d2afbe78 | 200 | might suit with your device well. |
a7fe49bf | 201 | |
7b2ee291 TI |
202 | There are a few special model option values: |
203 | - when 'nofixup' is passed, the device-specific fixups in the codec | |
204 | parser are skipped. | |
205 | - when `generic` is passed, the codec-specific parser is skipped and | |
206 | only the generic parser is used. | |
a7fe49bf | 207 | |
a7fe49bf | 208 | |
a7fe49bf TI |
209 | Speaker and Headphone Output |
210 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
211 | One of the most frequent (and obvious) bugs with HD-audio is the | |
212 | silent output from either or both of a built-in speaker and a | |
213 | headphone jack. In general, you should try a headphone output at | |
214 | first. A speaker output often requires more additional controls like | |
d2afbe78 TI |
215 | the external amplifier bits. Thus a headphone output has a slightly |
216 | better chance. | |
a7fe49bf TI |
217 | |
218 | Before making a bug report, double-check whether the mixer is set up | |
219 | correctly. The recent version of snd-hda-intel driver provides mostly | |
d2afbe78 TI |
220 | "Master" volume control as well as "Front" volume (where Front |
221 | indicates the front-channels). In addition, there can be individual | |
222 | "Headphone" and "Speaker" controls. | |
a7fe49bf TI |
223 | |
224 | Ditto for the speaker output. There can be "External Amplifier" | |
225 | switch on some codecs. Turn on this if present. | |
226 | ||
227 | Another related problem is the automatic mute of speaker output by | |
228 | headphone plugging. This feature is implemented in most cases, but | |
229 | not on every preset model or codec-support code. | |
230 | ||
231 | In anyway, try a different model option if you have such a problem. | |
232 | Some other models may match better and give you more matching | |
233 | functionality. If none of the available models works, send a bug | |
234 | report. See the bug report section for details. | |
235 | ||
236 | If you are masochistic enough to debug the driver problem, note the | |
237 | following: | |
238 | ||
239 | - The speaker (and the headphone, too) output often requires the | |
240 | external amplifier. This can be set usually via EAPD verb or a | |
241 | certain GPIO. If the codec pin supports EAPD, you have a better | |
242 | chance via SET_EAPD_BTL verb (0x70c). On others, GPIO pin (mostly | |
d2afbe78 | 243 | it's either GPIO0 or GPIO1) may turn on/off EAPD. |
a7fe49bf TI |
244 | - Some Realtek codecs require special vendor-specific coefficients to |
245 | turn on the amplifier. See patch_realtek.c. | |
246 | - IDT codecs may have extra power-enable/disable controls on each | |
247 | analog pin. See patch_sigmatel.c. | |
248 | - Very rare but some devices don't accept the pin-detection verb until | |
249 | triggered. Issuing GET_PIN_SENSE verb (0xf09) may result in the | |
250 | codec-communication stall. Some examples are found in | |
251 | patch_realtek.c. | |
252 | ||
253 | ||
254 | Capture Problems | |
255 | ~~~~~~~~~~~~~~~~ | |
d2afbe78 TI |
256 | The capture problems are often because of missing setups of mixers. |
257 | Thus, before submitting a bug report, make sure that you set up the | |
258 | mixer correctly. For example, both "Capture Volume" and "Capture | |
259 | Switch" have to be set properly in addition to the right "Capture | |
260 | Source" or "Input Source" selection. Some devices have "Mic Boost" | |
261 | volume or switch. | |
a7fe49bf TI |
262 | |
263 | When the PCM device is opened via "default" PCM (without pulse-audio | |
264 | plugin), you'll likely have "Digital Capture Volume" control as well. | |
265 | This is provided for the extra gain/attenuation of the signal in | |
266 | software, especially for the inputs without the hardware volume | |
267 | control such as digital microphones. Unless really needed, this | |
d2afbe78 TI |
268 | should be set to exactly 50%, corresponding to 0dB -- neither extra |
269 | gain nor attenuation. When you use "hw" PCM, i.e., a raw access PCM, | |
270 | this control will have no influence, though. | |
a7fe49bf TI |
271 | |
272 | It's known that some codecs / devices have fairly bad analog circuits, | |
273 | and the recorded sound contains a certain DC-offset. This is no bug | |
274 | of the driver. | |
275 | ||
d2afbe78 | 276 | Most of modern laptops have no analog CD-input connection. Thus, the |
a7fe49bf | 277 | recording from CD input won't work in many cases although the driver |
d2afbe78 | 278 | provides it as the capture source. Use CDDA instead. |
a7fe49bf TI |
279 | |
280 | The automatic switching of the built-in and external mic per plugging | |
281 | is implemented on some codec models but not on every model. Partly | |
282 | because of my laziness but mostly lack of testers. Feel free to | |
283 | submit the improvement patch to the author. | |
284 | ||
285 | ||
286 | Direct Debugging | |
287 | ~~~~~~~~~~~~~~~~ | |
f8bbd06b | 288 | If no model option gives you a better result, and you are a tough guy |
623b9f67 | 289 | to fight against evil, try debugging via hitting the raw HD-audio |
a7fe49bf TI |
290 | codec verbs to the device. Some tools are available: hda-emu and |
291 | hda-analyzer. The detailed description is found in the sections | |
292 | below. You'd need to enable hwdep for using these tools. See "Kernel | |
d2afbe78 | 293 | Configuration" section. |
a7fe49bf TI |
294 | |
295 | ||
296 | OTHER ISSUES | |
297 | ------------ | |
298 | ||
299 | Kernel Configuration | |
300 | ~~~~~~~~~~~~~~~~~~~~ | |
301 | In general, I recommend you to enable the sound debug option, | |
302 | `CONFIG_SND_DEBUG=y`, no matter whether you are debugging or not. | |
303 | This enables snd_printd() macro and others, and you'll get additional | |
304 | kernel messages at probing. | |
305 | ||
306 | In addition, you can enable `CONFIG_SND_DEBUG_VERBOSE=y`. But this | |
307 | will give you far more messages. Thus turn this on only when you are | |
308 | sure to want it. | |
309 | ||
310 | Don't forget to turn on the appropriate `CONFIG_SND_HDA_CODEC_*` | |
311 | options. Note that each of them corresponds to the codec chip, not | |
312 | the controller chip. Thus, even if lspci shows the Nvidia controller, | |
d2afbe78 TI |
313 | you may need to choose the option for other vendors. If you are |
314 | unsure, just select all yes. | |
a7fe49bf TI |
315 | |
316 | `CONFIG_SND_HDA_HWDEP` is a useful option for debugging the driver. | |
317 | When this is enabled, the driver creates hardware-dependent devices | |
318 | (one per each codec), and you have a raw access to the device via | |
d2afbe78 TI |
319 | these device files. For example, `hwC0D2` will be created for the |
320 | codec slot #2 of the first card (#0). For debug-tools such as | |
321 | hda-verb and hda-analyzer, the hwdep device has to be enabled. | |
322 | Thus, it'd be better to turn this on always. | |
a7fe49bf TI |
323 | |
324 | `CONFIG_SND_HDA_RECONFIG` is a new option, and this depends on the | |
325 | hwdep option above. When enabled, you'll have some sysfs files under | |
326 | the corresponding hwdep directory. See "HD-audio reconfiguration" | |
327 | section below. | |
328 | ||
329 | `CONFIG_SND_HDA_POWER_SAVE` option enables the power-saving feature. | |
330 | See "Power-saving" section below. | |
331 | ||
332 | ||
333 | Codec Proc-File | |
334 | ~~~~~~~~~~~~~~~ | |
335 | The codec proc-file is a treasure-chest for debugging HD-audio. | |
336 | It shows most of useful information of each codec widget. | |
337 | ||
338 | The proc file is located in /proc/asound/card*/codec#*, one file per | |
339 | each codec slot. You can know the codec vendor, product id and | |
340 | names, the type of each widget, capabilities and so on. | |
341 | This file, however, doesn't show the jack sensing state, so far. This | |
342 | is because the jack-sensing might be depending on the trigger state. | |
343 | ||
344 | This file will be picked up by the debug tools, and also it can be fed | |
345 | to the emulator as the primary codec information. See the debug tools | |
346 | section below. | |
347 | ||
348 | This proc file can be also used to check whether the generic parser is | |
349 | used. When the generic parser is used, the vendor/product ID name | |
350 | will appear as "Realtek ID 0262", instead of "Realtek ALC262". | |
351 | ||
352 | ||
353 | HD-Audio Reconfiguration | |
354 | ~~~~~~~~~~~~~~~~~~~~~~~~ | |
355 | This is an experimental feature to allow you re-configure the HD-audio | |
356 | codec dynamically without reloading the driver. The following sysfs | |
357 | files are available under each codec-hwdep device directory (e.g. | |
358 | /sys/class/sound/hwC0D0): | |
359 | ||
360 | vendor_id:: | |
361 | Shows the 32bit codec vendor-id hex number. You can change the | |
362 | vendor-id value by writing to this file. | |
363 | subsystem_id:: | |
364 | Shows the 32bit codec subsystem-id hex number. You can change the | |
365 | subsystem-id value by writing to this file. | |
366 | revision_id:: | |
367 | Shows the 32bit codec revision-id hex number. You can change the | |
368 | revision-id value by writing to this file. | |
369 | afg:: | |
370 | Shows the AFG ID. This is read-only. | |
371 | mfg:: | |
372 | Shows the MFG ID. This is read-only. | |
373 | name:: | |
374 | Shows the codec name string. Can be changed by writing to this | |
375 | file. | |
376 | modelname:: | |
377 | Shows the currently set `model` option. Can be changed by writing | |
378 | to this file. | |
379 | init_verbs:: | |
380 | The extra verbs to execute at initialization. You can add a verb by | |
d02b1f39 TI |
381 | writing to this file. Pass three numbers: nid, verb and parameter |
382 | (separated with a space). | |
a7fe49bf | 383 | hints:: |
d02b1f39 | 384 | Shows / stores hint strings for codec parsers for any use. |
7b2ee291 TI |
385 | Its format is `key = value`. For example, passing `jack_detect = no` |
386 | will disable the jack detection of the machine completely. | |
f1085c4f TI |
387 | init_pin_configs:: |
388 | Shows the initial pin default config values set by BIOS. | |
346ff70f | 389 | driver_pin_configs:: |
f1085c4f TI |
390 | Shows the pin default values set by the codec parser explicitly. |
391 | This doesn't show all pin values but only the changed values by | |
392 | the parser. That is, if the parser doesn't change the pin default | |
393 | config values by itself, this will contain nothing. | |
346ff70f TI |
394 | user_pin_configs:: |
395 | Shows the pin default config values to override the BIOS setup. | |
396 | Writing this (with two numbers, NID and value) appends the new | |
397 | value. The given will be used instead of the initial BIOS value at | |
5e7b8e0d TI |
398 | the next reconfiguration time. Note that this config will override |
399 | even the driver pin configs, too. | |
a7fe49bf TI |
400 | reconfig:: |
401 | Triggers the codec re-configuration. When any value is written to | |
402 | this file, the driver re-initialize and parses the codec tree | |
403 | again. All the changes done by the sysfs entries above are taken | |
404 | into account. | |
405 | clear:: | |
406 | Resets the codec, removes the mixer elements and PCM stuff of the | |
407 | specified codec, and clear all init verbs and hints. | |
408 | ||
39c2871e TI |
409 | For example, when you want to change the pin default configuration |
410 | value of the pin widget 0x14 to 0x9993013f, and let the driver | |
411 | re-configure based on that state, run like below: | |
412 | ------------------------------------------------------------------------ | |
413 | # echo 0x14 0x9993013f > /sys/class/sound/hwC0D0/user_pin_configs | |
414 | # echo 1 > /sys/class/sound/hwC0D0/reconfig | |
415 | ------------------------------------------------------------------------ | |
416 | ||
a7fe49bf | 417 | |
7b2ee291 TI |
418 | Hint Strings |
419 | ~~~~~~~~~~~~ | |
420 | The codec parser have several switches and adjustment knobs for | |
421 | matching better with the actual codec or device behavior. Many of | |
422 | them can be adjusted dynamically via "hints" strings as mentioned in | |
423 | the section above. For example, by passing `jack_detect = no` string | |
424 | via sysfs or a patch file, you can disable the jack detection, thus | |
425 | the codec parser will skip the features like auto-mute or mic | |
426 | auto-switch. As a boolean value, either `yes`, `no`, `true`, `false`, | |
427 | `1` or `0` can be passed. | |
428 | ||
429 | The generic parser supports the following hints: | |
430 | ||
431 | - jack_detect (bool): specify whether the jack detection is available | |
432 | at all on this machine; default true | |
433 | - inv_jack_detect (bool): indicates that the jack detection logic is | |
434 | inverted | |
435 | - trigger_sense (bool): indicates that the jack detection needs the | |
436 | explicit call of AC_VERB_SET_PIN_SENSE verb | |
437 | - inv_eapd (bool): indicates that the EAPD is implemented in the | |
438 | inverted logic | |
439 | - pcm_format_first (bool): sets the PCM format before the stream tag | |
440 | and channel ID | |
441 | - sticky_stream (bool): keep the PCM format, stream tag and ID as long | |
442 | as possible; default true | |
443 | - spdif_status_reset (bool): reset the SPDIF status bits at each time | |
444 | the SPDIF stream is set up | |
445 | - pin_amp_workaround (bool): the output pin may have multiple amp | |
446 | values | |
447 | - single_adc_amp (bool): ADCs can have only single input amps | |
448 | - auto_mute (bool): enable/disable the headphone auto-mute feature; | |
449 | default true | |
450 | - auto_mic (bool): enable/disable the mic auto-switch feature; default | |
451 | true | |
452 | - line_in_auto_switch (bool): enable/disable the line-in auto-switch | |
453 | feature; default false | |
454 | - need_dac_fix (bool): limits the DACs depending on the channel count | |
455 | - primary_hp (bool): probe headphone jacks as the primary outputs; | |
456 | default true | |
da96fb5b TI |
457 | - multi_io (bool): try probing multi-I/O config (e.g. shared |
458 | line-in/surround, mic/clfe jacks) | |
7b2ee291 TI |
459 | - multi_cap_vol (bool): provide multiple capture volumes |
460 | - inv_dmic_split (bool): provide split internal mic volume/switch for | |
461 | phase-inverted digital mics | |
462 | - indep_hp (bool): provide the independent headphone PCM stream and | |
463 | the corresponding mixer control, if available | |
464 | - add_stereo_mix_input (bool): add the stereo mix (analog-loopback | |
465 | mix) to the input mux if available | |
f811c3cf TI |
466 | - add_jack_modes (bool): add "xxx Jack Mode" enum controls to each |
467 | I/O jack for allowing to change the headphone amp and mic bias VREF | |
468 | capabilities | |
967b1307 TI |
469 | - power_save_node (bool): advanced power management for each widget, |
470 | controlling the power sate (D0/D3) of each widget node depending on | |
471 | the actual pin and stream states | |
472 | - power_down_unused (bool): power down the unused widgets, a subset of | |
473 | power_save_node, and will be dropped in future | |
967303da TI |
474 | - add_hp_mic (bool): add the headphone to capture source if possible |
475 | - hp_mic_detect (bool): enable/disable the hp/mic shared input for a | |
476 | single built-in mic case; default true | |
7b2ee291 TI |
477 | - mixer_nid (int): specifies the widget NID of the analog-loopback |
478 | mixer | |
479 | ||
480 | ||
76824825 TI |
481 | Early Patching |
482 | ~~~~~~~~~~~~~~ | |
483 | When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a | |
484 | firmware file for modifying the HD-audio setup before initializing the | |
485 | codec. This can work basically like the reconfiguration via sysfs in | |
486 | the above, but it does it before the first codec configuration. | |
487 | ||
1e7b8c87 | 488 | A patch file is a plain text file which looks like below: |
76824825 TI |
489 | |
490 | ------------------------------------------------------------------------ | |
491 | [codec] | |
492 | 0x12345678 0xabcd1234 2 | |
493 | ||
494 | [model] | |
495 | auto | |
496 | ||
497 | [pincfg] | |
498 | 0x12 0x411111f0 | |
499 | ||
500 | [verb] | |
501 | 0x20 0x500 0x03 | |
502 | 0x20 0x400 0xff | |
503 | ||
504 | [hint] | |
7b2ee291 | 505 | jack_detect = no |
76824825 TI |
506 | ------------------------------------------------------------------------ |
507 | ||
508 | The file needs to have a line `[codec]`. The next line should contain | |
509 | three numbers indicating the codec vendor-id (0x12345678 in the | |
510 | example), the codec subsystem-id (0xabcd1234) and the address (2) of | |
511 | the codec. The rest patch entries are applied to this specified codec | |
ef940b04 TI |
512 | until another codec entry is given. Passing 0 or a negative number to |
513 | the first or the second value will make the check of the corresponding | |
514 | field be skipped. It'll be useful for really broken devices that don't | |
515 | initialize SSID properly. | |
76824825 TI |
516 | |
517 | The `[model]` line allows to change the model name of the each codec. | |
518 | In the example above, it will be changed to model=auto. | |
519 | Note that this overrides the module option. | |
520 | ||
521 | After the `[pincfg]` line, the contents are parsed as the initial | |
522 | default pin-configurations just like `user_pin_configs` sysfs above. | |
523 | The values can be shown in user_pin_configs sysfs file, too. | |
524 | ||
525 | Similarly, the lines after `[verb]` are parsed as `init_verbs` | |
526 | sysfs entries, and the lines after `[hint]` are parsed as `hints` | |
527 | sysfs entries, respectively. | |
528 | ||
b09f3e78 TI |
529 | Another example to override the codec vendor id from 0x12345678 to |
530 | 0xdeadbeef is like below: | |
531 | ------------------------------------------------------------------------ | |
532 | [codec] | |
533 | 0x12345678 0xabcd1234 2 | |
534 | ||
535 | [vendor_id] | |
536 | 0xdeadbeef | |
537 | ------------------------------------------------------------------------ | |
538 | ||
539 | In the similar way, you can override the codec subsystem_id via | |
540 | `[subsystem_id]`, the revision id via `[revision_id]` line. | |
541 | Also, the codec chip name can be rewritten via `[chip_name]` line. | |
542 | ------------------------------------------------------------------------ | |
543 | [codec] | |
544 | 0x12345678 0xabcd1234 2 | |
545 | ||
546 | [subsystem_id] | |
547 | 0xffff1111 | |
548 | ||
549 | [revision_id] | |
550 | 0x10 | |
551 | ||
552 | [chip_name] | |
553 | My-own NEWS-0002 | |
554 | ------------------------------------------------------------------------ | |
555 | ||
1e7b8c87 TI |
556 | The hd-audio driver reads the file via request_firmware(). Thus, |
557 | a patch file has to be located on the appropriate firmware path, | |
558 | typically, /lib/firmware. For example, when you pass the option | |
820bc19d | 559 | `patch=hda-init.fw`, the file /lib/firmware/hda-init.fw must be |
1e7b8c87 TI |
560 | present. |
561 | ||
562 | The patch module option is specific to each card instance, and you | |
563 | need to give one file name for each instance, separated by commas. | |
564 | For example, if you have two cards, one for an on-board analog and one | |
565 | for an HDMI video board, you may pass patch option like below: | |
566 | ------------------------------------------------------------------------ | |
567 | options snd-hda-intel patch=on-board-patch,hdmi-patch | |
568 | ------------------------------------------------------------------------ | |
569 | ||
76824825 | 570 | |
a7fe49bf TI |
571 | Power-Saving |
572 | ~~~~~~~~~~~~ | |
573 | The power-saving is a kind of auto-suspend of the device. When the | |
574 | device is inactive for a certain time, the device is automatically | |
575 | turned off to save the power. The time to go down is specified via | |
576 | `power_save` module option, and this option can be changed dynamically | |
577 | via sysfs. | |
578 | ||
579 | The power-saving won't work when the analog loopback is enabled on | |
580 | some codecs. Make sure that you mute all unneeded signal routes when | |
581 | you want the power-saving. | |
582 | ||
583 | The power-saving feature might cause audible click noises at each | |
584 | power-down/up depending on the device. Some of them might be | |
585 | solvable, but some are hard, I'm afraid. Some distros such as | |
586 | openSUSE enables the power-saving feature automatically when the power | |
587 | cable is unplugged. Thus, if you hear noises, suspect first the | |
623b9f67 | 588 | power-saving. See /sys/module/snd_hda_intel/parameters/power_save to |
a7fe49bf TI |
589 | check the current value. If it's non-zero, the feature is turned on. |
590 | ||
7b2ee291 TI |
591 | The recent kernel supports the runtime PM for the HD-audio controller |
592 | chip, too. It means that the HD-audio controller is also powered up / | |
593 | down dynamically. The feature is enabled only for certain controller | |
594 | chips like Intel LynxPoint. You can enable/disable this feature | |
595 | forcibly by setting `power_save_controller` option, which is also | |
596 | available at /sys/module/snd_hda_intel/parameters directory. | |
597 | ||
a7fe49bf | 598 | |
d11b7fa3 TI |
599 | Tracepoints |
600 | ~~~~~~~~~~~ | |
601 | The hd-audio driver gives a few basic tracepoints. | |
602 | `hda:hda_send_cmd` traces each CORB write while `hda:hda_get_response` | |
603 | traces the response from RIRB (only when read from the codec driver). | |
ecf726f5 TI |
604 | `hda:hda_bus_reset` traces the bus-reset due to fatal error, etc, |
605 | `hda:hda_unsol_event` traces the unsolicited events, and | |
d11b7fa3 TI |
606 | `hda:hda_power_down` and `hda:hda_power_up` trace the power down/up |
607 | via power-saving behavior. | |
608 | ||
609 | Enabling all tracepoints can be done like | |
610 | ------------------------------------------------------------------------ | |
611 | # echo 1 > /sys/kernel/debug/tracing/events/hda/enable | |
612 | ------------------------------------------------------------------------ | |
613 | then after some commands, you can traces from | |
614 | /sys/kernel/debug/tracing/trace file. For example, when you want to | |
615 | trace what codec command is sent, enable the tracepoint like: | |
616 | ------------------------------------------------------------------------ | |
617 | # cat /sys/kernel/debug/tracing/trace | |
618 | # tracer: nop | |
619 | # | |
620 | # TASK-PID CPU# TIMESTAMP FUNCTION | |
621 | # | | | | | | |
622 | <...>-7807 [002] 105147.774889: hda_send_cmd: [0:0] val=e3a019 | |
623 | <...>-7807 [002] 105147.774893: hda_send_cmd: [0:0] val=e39019 | |
624 | <...>-7807 [002] 105147.999542: hda_send_cmd: [0:0] val=e3a01a | |
625 | <...>-7807 [002] 105147.999543: hda_send_cmd: [0:0] val=e3901a | |
626 | <...>-26764 [001] 349222.837143: hda_send_cmd: [0:0] val=e3a019 | |
627 | <...>-26764 [001] 349222.837148: hda_send_cmd: [0:0] val=e39019 | |
628 | <...>-26764 [001] 349223.058539: hda_send_cmd: [0:0] val=e3a01a | |
629 | <...>-26764 [001] 349223.058541: hda_send_cmd: [0:0] val=e3901a | |
630 | ------------------------------------------------------------------------ | |
631 | Here `[0:0]` indicates the card number and the codec address, and | |
632 | `val` shows the value sent to the codec, respectively. The value is | |
633 | a packed value, and you can decode it via hda-decode-verb program | |
634 | included in hda-emu package below. For example, the value e3a019 is | |
635 | to set the left output-amp value to 25. | |
636 | ------------------------------------------------------------------------ | |
637 | % hda-decode-verb 0xe3a019 | |
638 | raw value = 0x00e3a019 | |
639 | cid = 0, nid = 0x0e, verb = 0x3a0, parm = 0x19 | |
640 | raw value: verb = 0x3a0, parm = 0x19 | |
641 | verbname = set_amp_gain_mute | |
642 | amp raw val = 0xa019 | |
643 | output, left, idx=0, mute=0, val=25 | |
644 | ------------------------------------------------------------------------ | |
645 | ||
646 | ||
132bb7c0 TI |
647 | Development Tree |
648 | ~~~~~~~~~~~~~~~~ | |
649 | The latest development codes for HD-audio are found on sound git tree: | |
650 | ||
25d7d59d | 651 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git |
132bb7c0 TI |
652 | |
653 | The master branch or for-next branches can be used as the main | |
7b2ee291 TI |
654 | development branches in general while the development for the current |
655 | and next kernels are found in for-linus and for-next branches, | |
656 | respectively. | |
132bb7c0 TI |
657 | |
658 | If you are using the latest Linus tree, it'd be better to pull the | |
659 | above GIT tree onto it. If you are using the older kernels, an easy | |
660 | way to try the latest ALSA code is to build from the snapshot | |
661 | tarball. There are daily tarballs and the latest snapshot tarball. | |
662 | All can be built just like normal alsa-driver release packages, that | |
663 | is, installed via the usual spells: configure, make and make | |
664 | install(-modules). See INSTALL in the package. The snapshot tarballs | |
665 | are found at: | |
666 | ||
25d7d59d | 667 | - ftp://ftp.suse.com/pub/people/tiwai/snapshot/ |
132bb7c0 TI |
668 | |
669 | ||
a7fe49bf TI |
670 | Sending a Bug Report |
671 | ~~~~~~~~~~~~~~~~~~~~ | |
672 | If any model or module options don't work for your device, it's time | |
673 | to send a bug report to the developers. Give the following in your | |
674 | bug report: | |
675 | ||
676 | - Hardware vendor, product and model names | |
677 | - Kernel version (and ALSA-driver version if you built externally) | |
678 | - `alsa-info.sh` output; run with `--no-upload` option. See the | |
679 | section below about alsa-info | |
680 | ||
681 | If it's a regression, at best, send alsa-info outputs of both working | |
682 | and non-working kernels. This is really helpful because we can | |
683 | compare the codec registers directly. | |
684 | ||
685 | Send a bug report either the followings: | |
686 | ||
687 | kernel-bugzilla:: | |
0ea6e611 | 688 | https://bugzilla.kernel.org/ |
a7fe49bf TI |
689 | alsa-devel ML:: |
690 | alsa-devel@alsa-project.org | |
691 | ||
692 | ||
693 | DEBUG TOOLS | |
694 | ----------- | |
695 | ||
696 | This section describes some tools available for debugging HD-audio | |
697 | problems. | |
698 | ||
699 | alsa-info | |
700 | ~~~~~~~~~ | |
701 | The script `alsa-info.sh` is a very useful tool to gather the audio | |
702 | device information. You can fetch the latest version from: | |
703 | ||
704 | - http://www.alsa-project.org/alsa-info.sh | |
705 | ||
706 | Run this script as root, and it will gather the important information | |
707 | such as the module lists, module parameters, proc file contents | |
708 | including the codec proc files, mixer outputs and the control | |
709 | elements. As default, it will store the information onto a web server | |
710 | on alsa-project.org. But, if you send a bug report, it'd be better to | |
711 | run with `--no-upload` option, and attach the generated file. | |
712 | ||
713 | There are some other useful options. See `--help` option output for | |
714 | details. | |
715 | ||
ae374d66 TI |
716 | When a probe error occurs or when the driver obviously assigns a |
717 | mismatched model, it'd be helpful to load the driver with | |
718 | `probe_only=1` option (at best after the cold reboot) and run | |
719 | alsa-info at this state. With this option, the driver won't configure | |
720 | the mixer and PCM but just tries to probe the codec slot. After | |
721 | probing, the proc file is available, so you can get the raw codec | |
722 | information before modified by the driver. Of course, the driver | |
723 | isn't usable with `probe_only=1`. But you can continue the | |
724 | configuration via hwdep sysfs file if hda-reconfig option is enabled. | |
10e77dda JK |
725 | Using `probe_only` mask 2 skips the reset of HDA codecs (use |
726 | `probe_only=3` as module option). The hwdep interface can be used | |
727 | to determine the BIOS codec initialization. | |
ae374d66 | 728 | |
a7fe49bf TI |
729 | |
730 | hda-verb | |
731 | ~~~~~~~~ | |
732 | hda-verb is a tiny program that allows you to access the HD-audio | |
d2afbe78 | 733 | codec directly. You can execute a raw HD-audio codec verb with this. |
a7fe49bf TI |
734 | This program accesses the hwdep device, thus you need to enable the |
735 | kernel config `CONFIG_SND_HDA_HWDEP=y` beforehand. | |
736 | ||
737 | The hda-verb program takes four arguments: the hwdep device file, the | |
738 | widget NID, the verb and the parameter. When you access to the codec | |
739 | on the slot 2 of the card 0, pass /dev/snd/hwC0D2 to the first | |
740 | argument, typically. (However, the real path name depends on the | |
741 | system.) | |
742 | ||
743 | The second parameter is the widget number-id to access. The third | |
744 | parameter can be either a hex/digit number or a string corresponding | |
745 | to a verb. Similarly, the last parameter is the value to write, or | |
746 | can be a string for the parameter type. | |
747 | ||
748 | ------------------------------------------------------------------------ | |
749 | % hda-verb /dev/snd/hwC0D0 0x12 0x701 2 | |
750 | nid = 0x12, verb = 0x701, param = 0x2 | |
751 | value = 0x0 | |
752 | ||
753 | % hda-verb /dev/snd/hwC0D0 0x0 PARAMETERS VENDOR_ID | |
754 | nid = 0x0, verb = 0xf00, param = 0x0 | |
755 | value = 0x10ec0262 | |
756 | ||
757 | % hda-verb /dev/snd/hwC0D0 2 set_a 0xb080 | |
758 | nid = 0x2, verb = 0x300, param = 0xb080 | |
759 | value = 0x0 | |
760 | ------------------------------------------------------------------------ | |
761 | ||
762 | Although you can issue any verbs with this program, the driver state | |
763 | won't be always updated. For example, the volume values are usually | |
764 | cached in the driver, and thus changing the widget amp value directly | |
765 | via hda-verb won't change the mixer value. | |
766 | ||
7b2ee291 TI |
767 | The hda-verb program is included now in alsa-tools: |
768 | ||
769 | - git://git.alsa-project.org/alsa-tools.git | |
770 | ||
771 | Also, the old stand-alone package is found in the ftp directory: | |
a7fe49bf | 772 | |
25d7d59d | 773 | - ftp://ftp.suse.com/pub/people/tiwai/misc/ |
a7fe49bf TI |
774 | |
775 | Also a git repository is available: | |
776 | ||
777 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-verb.git | |
778 | ||
779 | See README file in the tarball for more details about hda-verb | |
780 | program. | |
781 | ||
782 | ||
783 | hda-analyzer | |
784 | ~~~~~~~~~~~~ | |
785 | hda-analyzer provides a graphical interface to access the raw HD-audio | |
786 | control, based on pyGTK2 binding. It's a more powerful version of | |
d2afbe78 | 787 | hda-verb. The program gives you an easy-to-use GUI stuff for showing |
a7fe49bf TI |
788 | the widget information and adjusting the amp values, as well as the |
789 | proc-compatible output. | |
790 | ||
11caa3bf | 791 | The hda-analyzer: |
a7fe49bf TI |
792 | |
793 | - http://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer | |
794 | ||
11caa3bf AF |
795 | is a part of alsa.git repository in alsa-project.org: |
796 | ||
797 | - git://git.alsa-project.org/alsa.git | |
a7fe49bf | 798 | |
623b9f67 TI |
799 | Codecgraph |
800 | ~~~~~~~~~~ | |
801 | Codecgraph is a utility program to generate a graph and visualizes the | |
802 | codec-node connection of a codec chip. It's especially useful when | |
803 | you analyze or debug a codec without a proper datasheet. The program | |
804 | parses the given codec proc file and converts to SVG via graphiz | |
805 | program. | |
806 | ||
807 | The tarball and GIT trees are found in the web page at: | |
808 | ||
809 | - http://helllabs.org/codecgraph/ | |
810 | ||
811 | ||
a7fe49bf TI |
812 | hda-emu |
813 | ~~~~~~~ | |
d2afbe78 | 814 | hda-emu is an HD-audio emulator. The main purpose of this program is |
a7fe49bf TI |
815 | to debug an HD-audio codec without the real hardware. Thus, it |
816 | doesn't emulate the behavior with the real audio I/O, but it just | |
817 | dumps the codec register changes and the ALSA-driver internal changes | |
818 | at probing and operating the HD-audio driver. | |
819 | ||
820 | The program requires a codec proc-file to simulate. Get a proc file | |
821 | for the target codec beforehand, or pick up an example codec from the | |
822 | codec proc collections in the tarball. Then, run the program with the | |
823 | proc file, and the hda-emu program will start parsing the codec file | |
824 | and simulates the HD-audio driver: | |
825 | ||
826 | ------------------------------------------------------------------------ | |
827 | % hda-emu codecs/stac9200-dell-d820-laptop | |
828 | # Parsing.. | |
829 | hda_codec: Unknown model for STAC9200, using BIOS defaults | |
830 | hda_codec: pin nid 08 bios pin config 40c003fa | |
831 | .... | |
832 | ------------------------------------------------------------------------ | |
833 | ||
834 | The program gives you only a very dumb command-line interface. You | |
835 | can get a proc-file dump at the current state, get a list of control | |
836 | (mixer) elements, set/get the control element value, simulate the PCM | |
837 | operation, the jack plugging simulation, etc. | |
838 | ||
839 | The package is found in: | |
840 | ||
25d7d59d | 841 | - ftp://ftp.suse.com/pub/people/tiwai/misc/ |
a7fe49bf TI |
842 | |
843 | A git repository is available: | |
844 | ||
845 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git | |
846 | ||
847 | See README file in the tarball for more details about hda-emu | |
848 | program. | |
7b2ee291 TI |
849 | |
850 | ||
851 | hda-jack-retask | |
852 | ~~~~~~~~~~~~~~~ | |
853 | hda-jack-retask is a user-friendly GUI program to manipulate the | |
854 | HD-audio pin control for jack retasking. If you have a problem about | |
855 | the jack assignment, try this program and check whether you can get | |
856 | useful results. Once when you figure out the proper pin assignment, | |
857 | it can be fixed either in the driver code statically or via passing a | |
858 | firmware patch file (see "Early Patching" section). | |
859 | ||
860 | The program is included in alsa-tools now: | |
861 | ||
862 | - git://git.alsa-project.org/alsa-tools.git | |
863 |