Register Description¶

The register is accessed via processing coefficient 0x36 on NID 20h. Bits notidentified below have no discernible effect on my machine, a Dell XPS 13 9350:

MSB                           LSB+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |h|S|L|         | B |R|       | Known bits+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+|0|0|1|1|  0x7  |0|0x0|1|  0x7  | Reset value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1Ah input select (B): 2 bits

When zero, expose the PC Beep line (from the internal beep generator, whenenabled with the Set Beep Generation verb on NID 01h, or else from theexternal PCBEEP pin) on the 1Ah pin node. When nonzero, expose the headphonejack (or possibly Line In on some machines) input instead. If PC Beep isselected, the 1Ah boost control has no effect.

Amplify 1Ah loopback, left (L): 1 bit

Amplify the left channel of 1Ah before mixing it into outputs as specifiedby h and S bits. Does not affect the level of 1Ah exposed to other widgets.

Amplify 1Ah loopback, right (R): 1 bit

Amplify the right channel of 1Ah before mixing it into outputs as specifiedby h and S bits. Does not affect the level of 1Ah exposed to other widgets.

Loopback 1Ah to 21h [active low] (h): 1 bit

When zero, mix 1Ah (possibly with amplification, depending on L and R bits)into 21h (headphone jack on my machine). Mixed signal respects the mutesetting on 21h.

Loopback 1Ah to 14h (S): 1 bit

When one, mix 1Ah (possibly with amplification, depending on L and R bits)into 14h (internal speaker on my machine). Mixed signalignores the mutesetting on 14h and is present whenever 14h is configured as an output.

Path diagrams¶

1Ah input selection (DIV is the PC Beep divider set on NID 01h):

<Beep generator>   <PCBEEP pin>    <Headphone jack>        |                |                |        +--DIV--+--!DIV--+       {1Ah boost control}                |                         |                +--(b == 0)--+--(b != 0)--+                             |             >1Ah (Beep/Headphone Mic/Line In)<

Loopback of 1Ah to 21h/14h:

     <1Ah (Beep/Headphone Mic/Line In)>                     |              {amplify if L/R}                     |        +-----!h-----+-----S-----+        |                        |{21h mute control}               |        |                        |>21h (Headphone)<     >14h (Internal Speaker)<

Background¶

All Realtek HDA codecs have a vendor-defined widget with node ID 20h whichprovides access to a bank of registers that control various codec functions.Registers are read and written via the standard HDA processing coefficientverbs (Set/Get Coefficient Index, Set/Get Processing Coefficient). The node isnamed “Realtek Vendor Registers” in public datasheets’ verb listings and,apart from that, is entirely undocumented.

This particular register, exposed at coefficient 0x36 and named in commits fromRealtek, is of note: unlike most registers, which seem to control detailedamplifier parameters not in scope of the HDA specification, it controls audiorouting which could just as easily have been defined using standard HDA mixerand selector widgets.

Specifically, it selects between two sources for the input pin widget with NodeID (NID) 1Ah: the widget’s signal can come either from an audio jack (on mylaptop, a Dell XPS 13 9350, it’s the headphone jack, but comments in Realtekcommits indicate that it might be a Line In on some machines) or from the PCBeep line (which is itself multiplexed between the codec’s internal beepgenerator and external PCBEEP pin, depending on if the beep generator isenabled via verbs on NID 01h). Additionally, it can mix (with optionalamplification) that signal onto the 21h and/or 14h output pins.

The register’s reset value is 0x3717, corresponding to PC Beep on 1Ah that isthen amplified and mixed into both the headphones and the speakers. Not onlydoes this violate the HDA specification, which says that “[a vendor definedbeep input pin] connection may be maintainedonly while the Link reset(RST#) is asserted”, it means that we cannot ignore the register if we careabout the input that 1Ah would otherwise expose or if the PCBEEP trace ispoorly shielded and picks up chassis noise (both of which are the case on mymachine).

Unfortunately, there are lots of ways to get this register configuration wrong.Linux, it seems, has gone through most of them. For one, the register resetsafter S3 suspend: judging by existing code, this isn’t the case for all vendorregisters, and it’s led to some fixes that improve behavior on cold boot butdon’t last after suspend. Other fixes have successfully switched the 1Ah inputaway from PC Beep but have failed to disable both loopback paths. On mymachine, this means that the headphone input is amplified and looped back tothe headphone output, which uses the exact same pins! As you might expect, thiscauses terrible headphone noise, the character of which is controlled by the1Ah boost control. (If you’ve seen instructions online to fix XPS 13 headphonenoise by changing “Headphone Mic Boost” in ALSA, now you know why.)

The information here has been obtained through black-box reverse engineering ofthe ALC256 codec’s behavior and is not guaranteed to be correct. It likelyalso applies for the ALC255, ALC257, ALC235, and ALC236, since those codecsseem to be close relatives of the ALC256. (They all share one initializationfunction.) Additionally, other codecs like the ALC225 and ALC285 also have thisregister, judging by existing fixups inpatch_realtek.c, but specificdata (e.g. node IDs, bit positions, pin mappings) for those codecs may differfrom what I’ve described here.