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