notes.rst 35 KB

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