| MORE NOTES ON HD-AUDIO DRIVER |
| ============================= |
| Takashi Iwai <tiwai@suse.de> |
| |
| |
| GENERAL |
| ------- |
| |
| HD-audio is the new standard on-board audio component on modern PCs |
| after AC97. Although Linux has been supporting HD-audio since long |
| time ago, there are often problems with new machines. A part of the |
| problem is broken BIOS, and rest is the driver implementation. This |
| document explains the trouble-shooting and debugging methods for the |
| HD-audio hardware. |
| |
| The HD-audio component consists of two parts: the controller chip and |
| the codec chips on the HD-audio bus. Linux provides a single driver |
| for all controllers, snd-hda-intel. Since the HD-audio controllers |
| are supposed to be compatible, the single snd-hda-driver should work |
| in most cases. But, not surprisingly, there are known bugs and issues |
| specific to each controller type. The snd-hda-intel driver has a |
| bunch of workarounds for these as described below. |
| |
| A controller may have multiple codecs. Usually you have one audio |
| codec and optionally one modem codec. In some cases, there can be |
| multiple audio codecs, e.g. for analog and digital outputs, but the |
| driver might not work properly. |
| |
| The snd-hda-intel driver has several different codec parsers depending |
| on the codec. It has a generic parser as a fallback, but this |
| functionality is fairly limited until now. Instead of the generic |
| parser, usually the codec-specific parser (coded in patch_*.c) is used |
| for the codec-specific implementations. The details about the |
| codec-specific problems are explained in the later sections. |
| |
| If you are interested in the deep debugging of HD-audio, read the |
| HD-audio specification at first. The specification is found on |
| Intel's web page, for example: |
| |
| - http://www.intel.com/standards/hdaudio/ |
| |
| |
| HD-AUDIO CONTROLLER |
| ------------------- |
| |
| DMA-Position Problem |
| ~~~~~~~~~~~~~~~~~~~~ |
| The most common problem of the controller is the inaccurate DMA |
| pointer reporting. The DMA pointer for playback and capture can be |
| read in two ways, either via a LPIB register or via a position-buffer |
| map. As default the driver tries to reads from the io-mapped |
| position-buffer, and falls back to LPIB if it appears unupdated. |
| However, this detection isn't perfect on some devices. In such a |
| case, you can change the default method via `position_fix` option. |
| |
| `position_fix=1` means to use LPIB method explicitly. |
| `position_fix=2` means to use the position-buffer. 0 is the default |
| value, the automatic check. If you get a problem of repeated sounds, |
| this option might help. |
| |
| In addition to that, every controller is known to be broken regarding |
| the wake-up timing. It wakes up a few samples before actually |
| processing the data on the buffer. This caused a lot of problems, for |
| example, with ALSA dmix or JACK. Since 2.6.27 kernel, the driver puts |
| an artificial delay to the wake up timing. This delay is controlled |
| via `bdl_pos_adj` option. |
| |
| When `bdl_pos_adj` is a negative value (as default), it's assigned to |
| an appropriate value depending on the controller chip. For Intel |
| chip, it'd be 1 while it'd be 32 for others. Usually this works. |
| Only in case it doesn't work and you get warning messages, you should |
| change to other values. |
| |
| |
| Codec-Probing Problem |
| ~~~~~~~~~~~~~~~~~~~~~ |
| A less often but a more severe problem is the codec probing. When |
| BIOS reports the available codec slots wrongly, the driver gets |
| confused and tries to access the non-existing codec slot. This often |
| results in the total screw-up, and destruct the further communication |
| with the codec chips. The symptom appears usually as the error |
| message like: |
| ------------------------------------------------------------------------ |
| hda_intel: azx_get_response timeout, switching to polling mode: \ |
| last cmd=0x12345678 |
| hda_intel: azx_get_response timeout, switching to single_cmd mode: \ |
| last cmd=0x12345678 |
| ------------------------------------------------------------------------ |
| |
| The first line is a warning, and this is usually relatively harmless. |
| It means that the codec response isn't notified via an IRQ. The |
| driver uses explicit polling method to read the response. It gives |
| very slight CPU overhead, but you'd unlikely notice it. |
| |
| The second line is, however, a fatal error. If this happens, usually |
| it means that something is really wrong. Most likely you are |
| accessing a non-existing codec slot. |
| |
| Thus, if the second error message appears, try to narrow the probed |
| codec slots via `probe_mask` option. It's a bitmask, and each bit |
| corresponding to the codec slot. For example, to probe only the |
| first slot, pass `probe_mask=1`. For the first and the third slots, |
| pass `probe_mask=5` (where 5 = 1 | 4), and so on. |
| |
| Since 2.6.29 kernel, the driver has a more robust probing method, so |
| this error might happen rarely, though. |
| |
| |
| Interrupt Handling |
| ~~~~~~~~~~~~~~~~~~ |
| In rare but some cases, the interrupt isn't properly handled as |
| default. You would notice this by the DMA transfer error reported by |
| ALSA PCM core, for example. Using MSI might help in such a case. |
| Pass `enable_msi=1` option for enabling MSI. |
| |
| |
| HD-AUDIO CODEC |
| -------------- |
| |
| Model Option |
| ~~~~~~~~~~~~ |
| The most common problems with the HD-audio driver is the unsupported |
| codec features or the mismatched device configuration. Most of |
| codec-specific code has several preset models, either to override the |
| BIOS setup or to provide more comprehensive features. |
| |
| The driver checks PCI SSID and looks through the static configuration |
| table until any matching entry is found. If you have a new machine, |
| you may see a message like below: |
| ------------------------------------------------------------------------ |
| hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... |
| ------------------------------------------------------------------------ |
| Even if you such a message, DON'T PANIC. Take a deep breath (and keep |
| your towel). First of all, it's an informational message, no warning, |
| no error. This means that the PCI SSID of your device isn't listed in |
| the known preset model list. But, this doesn't mean that the driver |
| is broken. Many codec-driver provides the automatic configuration |
| based on the BIOS setup. |
| |
| The HD-audio codec has usually "pin" widgets, and BIOS sets the default |
| configuration of each pin, which indicates the location, the |
| connection type, the jack color, etc. The HD-audio driver can guess |
| the right connection judging from these default configuration values. |
| However -- some codec support codes, such as patch_analog.c, don't |
| support the automatic probing (yet as of 2.6.28). And, BIOS is often, |
| yes, pretty often broken. It sets up wrong values and screws up the |
| driver. |
| |
| The preset model is provided basically to override such a situation. |
| When the matching preset model is found in the list, the driver |
| assumes the static configuration of that preset and builds the mixer |
| and PCM based on the static information. Thus, if you have a newer |
| machine with a slightly different PCI SSID from the existing one, you |
| may have a good chance to re-use the same model. You can pass the |
| `model` option to specify the preset model instead of PCI SSID |
| look-up. |
| |
| What `model` option values are available depends on the codec chip. |
| Check your codec chip from the codec proc file (see "Codec Proc-File" |
| section below). It will show the vendor/product name of your codec |
| chip. Then, see Documentation/sound/alsa/ALSA-Configuration.txt file. |
| In the section of HD-audio driver, you can find a list of codecs and |
| `model` options belonging to each codec. For example, for Realtek |
| ALC262 codec chip, pass `model=ultra` for devices that are compatible |
| with Samsung Q1 Ultra. |
| |
| Thus, the first thing you can do for any brand-new, unsupported |
| HD-audio hardware is to check HD-audio codec and several different |
| `model` option values. If you have a luck, some of them might suit |
| with your device well. |
| |
| Some codecs such as ALC880 have a special model option `model=test`. |
| This configures the driver to provide as many mixer controls as |
| possible for every single pin feature except for the unsolicited |
| events (and maybe some other specials). Adjust each mixer element and |
| try the I/O in the way of trial-and-error until figuring out the whole |
| I/O pin mappings. |
| |
| Note that `model=generic` has a special meaning. It means to use the |
| generic parser regardless of the codec. Usually the codec-specific |
| parser is much better than the generic parser (as now). Thus this |
| option is more about the debugging purpose. |
| |
| |
| Speaker and Headphone Output |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| One of the most frequent (and obvious) bugs with HD-audio is the |
| silent output from either or both of a built-in speaker and a |
| headphone jack. In general, you should try a headphone output at |
| first. A speaker output often requires more additional controls like |
| the amplifier. Thus a headphone output has a slightly better chance. |
| |
| Before making a bug report, double-check whether the mixer is set up |
| correctly. The recent version of snd-hda-intel driver provides mostly |
| "Master" volume control as well as "Front" volume. In addition, there |
| are individual "Headphone" and "Speaker" controls. |
| |
| Ditto for the speaker output. There can be "External Amplifier" |
| switch on some codecs. Turn on this if present. |
| |
| Another related problem is the automatic mute of speaker output by |
| headphone plugging. This feature is implemented in most cases, but |
| not on every preset model or codec-support code. |
| |
| In anyway, try a different model option if you have such a problem. |
| Some other models may match better and give you more matching |
| functionality. If none of the available models works, send a bug |
| report. See the bug report section for details. |
| |
| If you are masochistic enough to debug the driver problem, note the |
| following: |
| |
| - The speaker (and the headphone, too) output often requires the |
| external amplifier. This can be set usually via EAPD verb or a |
| certain GPIO. If the codec pin supports EAPD, you have a better |
| chance via SET_EAPD_BTL verb (0x70c). On others, GPIO pin (mostly |
| it's either GPIO0 or GPIO1) can turn on/off EAPD. |
| - Some Realtek codecs require special vendor-specific coefficients to |
| turn on the amplifier. See patch_realtek.c. |
| - IDT codecs may have extra power-enable/disable controls on each |
| analog pin. See patch_sigmatel.c. |
| - Very rare but some devices don't accept the pin-detection verb until |
| triggered. Issuing GET_PIN_SENSE verb (0xf09) may result in the |
| codec-communication stall. Some examples are found in |
| patch_realtek.c. |
| |
| |
| Capture Problems |
| ~~~~~~~~~~~~~~~~ |
| The capture problems are often missing setups of mixers. Thus, before |
| submitting a bug report, make sure that you set up the mixer |
| correctly. For example, both "Capture Volume" and "Capture Switch" |
| have to be set properly in addition to the right "Capture Source" or |
| "Input Source" selection. Some devices have "Mic Boost" volume or |
| switch. |
| |
| When the PCM device is opened via "default" PCM (without pulse-audio |
| plugin), you'll likely have "Digital Capture Volume" control as well. |
| This is provided for the extra gain/attenuation of the signal in |
| software, especially for the inputs without the hardware volume |
| control such as digital microphones. Unless really needed, this |
| should be set to exactly 50%, corresponding to 0dB. When you use "hw" |
| PCM, i.e., a raw access PCM, this control will have no influence, |
| though. |
| |
| It's known that some codecs / devices have fairly bad analog circuits, |
| and the recorded sound contains a certain DC-offset. This is no bug |
| of the driver. |
| |
| Most of modern laptops have no analog CD-input connection. Thus, the |
| recording from CD input won't work in many cases although the driver |
| provides it as the capture source. |
| |
| The automatic switching of the built-in and external mic per plugging |
| is implemented on some codec models but not on every model. Partly |
| because of my laziness but mostly lack of testers. Feel free to |
| submit the improvement patch to the author. |
| |
| |
| Direct Debugging |
| ~~~~~~~~~~~~~~~~ |
| If no model option gives you a better result, and you are a touch guy |
| to fight again the evil, try debugging via hitting the raw HD-audio |
| codec verbs to the device. Some tools are available: hda-emu and |
| hda-analyzer. The detailed description is found in the sections |
| below. You'd need to enable hwdep for using these tools. See "Kernel |
| Configuration". |
| |
| |
| OTHER ISSUES |
| ------------ |
| |
| Kernel Configuration |
| ~~~~~~~~~~~~~~~~~~~~ |
| In general, I recommend you to enable the sound debug option, |
| `CONFIG_SND_DEBUG=y`, no matter whether you are debugging or not. |
| This enables snd_printd() macro and others, and you'll get additional |
| kernel messages at probing. |
| |
| In addition, you can enable `CONFIG_SND_DEBUG_VERBOSE=y`. But this |
| will give you far more messages. Thus turn this on only when you are |
| sure to want it. |
| |
| Don't forget to turn on the appropriate `CONFIG_SND_HDA_CODEC_*` |
| options. Note that each of them corresponds to the codec chip, not |
| the controller chip. Thus, even if lspci shows the Nvidia controller, |
| you may choose the option for other vendors. If you are unsure, just |
| choose all yes. |
| |
| `CONFIG_SND_HDA_HWDEP` is a useful option for debugging the driver. |
| When this is enabled, the driver creates hardware-dependent devices |
| (one per each codec), and you have a raw access to the device via |
| hda-verb program. For example, `hwC0D2` will be created for the card |
| 0 codec slot #2. For debug tools such as hda-verb and hda-analyzer, |
| the hwdep device has to be enabled. Thus, turn this on always. |
| |
| `CONFIG_SND_HDA_RECONFIG` is a new option, and this depends on the |
| hwdep option above. When enabled, you'll have some sysfs files under |
| the corresponding hwdep directory. See "HD-audio reconfiguration" |
| section below. |
| |
| `CONFIG_SND_HDA_POWER_SAVE` option enables the power-saving feature. |
| See "Power-saving" section below. |
| |
| |
| Codec Proc-File |
| ~~~~~~~~~~~~~~~ |
| The codec proc-file is a treasure-chest for debugging HD-audio. |
| It shows most of useful information of each codec widget. |
| |
| The proc file is located in /proc/asound/card*/codec#*, one file per |
| each codec slot. You can know the codec vendor, product id and |
| names, the type of each widget, capabilities and so on. |
| This file, however, doesn't show the jack sensing state, so far. This |
| is because the jack-sensing might be depending on the trigger state. |
| |
| This file will be picked up by the debug tools, and also it can be fed |
| to the emulator as the primary codec information. See the debug tools |
| section below. |
| |
| This proc file can be also used to check whether the generic parser is |
| used. When the generic parser is used, the vendor/product ID name |
| will appear as "Realtek ID 0262", instead of "Realtek ALC262". |
| |
| |
| HD-Audio Reconfiguration |
| ~~~~~~~~~~~~~~~~~~~~~~~~ |
| This is an experimental feature to allow you re-configure the HD-audio |
| codec dynamically without reloading the driver. The following sysfs |
| files are available under each codec-hwdep device directory (e.g. |
| /sys/class/sound/hwC0D0): |
| |
| vendor_id:: |
| Shows the 32bit codec vendor-id hex number. You can change the |
| vendor-id value by writing to this file. |
| subsystem_id:: |
| Shows the 32bit codec subsystem-id hex number. You can change the |
| subsystem-id value by writing to this file. |
| revision_id:: |
| Shows the 32bit codec revision-id hex number. You can change the |
| revision-id value by writing to this file. |
| afg:: |
| Shows the AFG ID. This is read-only. |
| mfg:: |
| Shows the MFG ID. This is read-only. |
| name:: |
| Shows the codec name string. Can be changed by writing to this |
| file. |
| modelname:: |
| Shows the currently set `model` option. Can be changed by writing |
| to this file. |
| init_verbs:: |
| The extra verbs to execute at initialization. You can add a verb by |
| writing to this file. Pass tree numbers, nid, verb and parameter. |
| hints:: |
| Shows hint strings for codec parsers for any use. Right now it's |
| not used. |
| reconfig:: |
| Triggers the codec re-configuration. When any value is written to |
| this file, the driver re-initialize and parses the codec tree |
| again. All the changes done by the sysfs entries above are taken |
| into account. |
| clear:: |
| Resets the codec, removes the mixer elements and PCM stuff of the |
| specified codec, and clear all init verbs and hints. |
| |
| |
| Power-Saving |
| ~~~~~~~~~~~~ |
| The power-saving is a kind of auto-suspend of the device. When the |
| device is inactive for a certain time, the device is automatically |
| turned off to save the power. The time to go down is specified via |
| `power_save` module option, and this option can be changed dynamically |
| via sysfs. |
| |
| The power-saving won't work when the analog loopback is enabled on |
| some codecs. Make sure that you mute all unneeded signal routes when |
| you want the power-saving. |
| |
| The power-saving feature might cause audible click noises at each |
| power-down/up depending on the device. Some of them might be |
| solvable, but some are hard, I'm afraid. Some distros such as |
| openSUSE enables the power-saving feature automatically when the power |
| cable is unplugged. Thus, if you hear noises, suspect first the |
| power-saving. See /sys/modules/snd_hda_intel/parameters/power_save to |
| check the current value. If it's non-zero, the feature is turned on. |
| |
| |
| Sending a Bug Report |
| ~~~~~~~~~~~~~~~~~~~~ |
| If any model or module options don't work for your device, it's time |
| to send a bug report to the developers. Give the following in your |
| bug report: |
| |
| - Hardware vendor, product and model names |
| - Kernel version (and ALSA-driver version if you built externally) |
| - `alsa-info.sh` output; run with `--no-upload` option. See the |
| section below about alsa-info |
| |
| If it's a regression, at best, send alsa-info outputs of both working |
| and non-working kernels. This is really helpful because we can |
| compare the codec registers directly. |
| |
| Send a bug report either the followings: |
| |
| kernel-bugzilla:: |
| http://bugme.linux-foundation.org/ |
| alsa-devel ML:: |
| alsa-devel@alsa-project.org |
| |
| |
| DEBUG TOOLS |
| ----------- |
| |
| This section describes some tools available for debugging HD-audio |
| problems. |
| |
| alsa-info |
| ~~~~~~~~~ |
| The script `alsa-info.sh` is a very useful tool to gather the audio |
| device information. You can fetch the latest version from: |
| |
| - http://www.alsa-project.org/alsa-info.sh |
| |
| Run this script as root, and it will gather the important information |
| such as the module lists, module parameters, proc file contents |
| including the codec proc files, mixer outputs and the control |
| elements. As default, it will store the information onto a web server |
| on alsa-project.org. But, if you send a bug report, it'd be better to |
| run with `--no-upload` option, and attach the generated file. |
| |
| There are some other useful options. See `--help` option output for |
| details. |
| |
| |
| hda-verb |
| ~~~~~~~~ |
| hda-verb is a tiny program that allows you to access the HD-audio |
| codec directly. It executes a HD-audio codec verb directly. |
| This program accesses the hwdep device, thus you need to enable the |
| kernel config `CONFIG_SND_HDA_HWDEP=y` beforehand. |
| |
| The hda-verb program takes four arguments: the hwdep device file, the |
| widget NID, the verb and the parameter. When you access to the codec |
| on the slot 2 of the card 0, pass /dev/snd/hwC0D2 to the first |
| argument, typically. (However, the real path name depends on the |
| system.) |
| |
| The second parameter is the widget number-id to access. The third |
| parameter can be either a hex/digit number or a string corresponding |
| to a verb. Similarly, the last parameter is the value to write, or |
| can be a string for the parameter type. |
| |
| ------------------------------------------------------------------------ |
| % hda-verb /dev/snd/hwC0D0 0x12 0x701 2 |
| nid = 0x12, verb = 0x701, param = 0x2 |
| value = 0x0 |
| |
| % hda-verb /dev/snd/hwC0D0 0x0 PARAMETERS VENDOR_ID |
| nid = 0x0, verb = 0xf00, param = 0x0 |
| value = 0x10ec0262 |
| |
| % hda-verb /dev/snd/hwC0D0 2 set_a 0xb080 |
| nid = 0x2, verb = 0x300, param = 0xb080 |
| value = 0x0 |
| ------------------------------------------------------------------------ |
| |
| Although you can issue any verbs with this program, the driver state |
| won't be always updated. For example, the volume values are usually |
| cached in the driver, and thus changing the widget amp value directly |
| via hda-verb won't change the mixer value. |
| |
| The hda-verb program is found in the ftp directory: |
| |
| - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ |
| |
| Also a git repository is available: |
| |
| - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-verb.git |
| |
| See README file in the tarball for more details about hda-verb |
| program. |
| |
| |
| hda-analyzer |
| ~~~~~~~~~~~~ |
| hda-analyzer provides a graphical interface to access the raw HD-audio |
| control, based on pyGTK2 binding. It's a more powerful version of |
| hda-verb. The program gives you a easy-to-use GUI stuff for showing |
| the widget information and adjusting the amp values, as well as the |
| proc-compatible output. |
| |
| The hda-analyzer is a part of alsa.git repository in |
| alsa-project.org: |
| |
| - http://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer |
| |
| |
| hda-emu |
| ~~~~~~~ |
| hda-emu is a HD-audio emulator. The main purpose of this program is |
| to debug an HD-audio codec without the real hardware. Thus, it |
| doesn't emulate the behavior with the real audio I/O, but it just |
| dumps the codec register changes and the ALSA-driver internal changes |
| at probing and operating the HD-audio driver. |
| |
| The program requires a codec proc-file to simulate. Get a proc file |
| for the target codec beforehand, or pick up an example codec from the |
| codec proc collections in the tarball. Then, run the program with the |
| proc file, and the hda-emu program will start parsing the codec file |
| and simulates the HD-audio driver: |
| |
| ------------------------------------------------------------------------ |
| % hda-emu codecs/stac9200-dell-d820-laptop |
| # Parsing.. |
| hda_codec: Unknown model for STAC9200, using BIOS defaults |
| hda_codec: pin nid 08 bios pin config 40c003fa |
| .... |
| ------------------------------------------------------------------------ |
| |
| The program gives you only a very dumb command-line interface. You |
| can get a proc-file dump at the current state, get a list of control |
| (mixer) elements, set/get the control element value, simulate the PCM |
| operation, the jack plugging simulation, etc. |
| |
| The package is found in: |
| |
| - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ |
| |
| A git repository is available: |
| |
| - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git |
| |
| See README file in the tarball for more details about hda-emu |
| program. |