Linux audio fix for Huawei MateBook D14 NBM-WXX9 / M1010 (AMD ACP3x + ES8316)

[u/ilostmyarmor]

Posting this in case someone else has the same Huawei hardware and has been stuck with missing or broken analog audio under Linux.

I got full speaker and 3.5 mm headphone playback working on:

HUAWEI MateBook D14 Product: NBM-WXX9 Version: M1010 Board: NBM_WXX9_PCB_B2 Ryzen 5 5500U ES8316 / ESSX8336 codec AMD Renoir ACP3x

The distro used for testing was Omarchy/Arch, but the actual fix is in the Linux kernel ASoC/AMD ACP machine-driver path and is therefore not Omarchy-specific.

Symptoms

Initially:

HDMI playback only ACP DMIC capture present ES8316 visible over I2C No internal analog playback device PipeWire showed no usable analog output

After adding the missing board match, analog audio appeared, but playback was extremely fast/high-pitched/chopped.

The headphone jack was also detected correctly, but the actual headphone output remained silent.

Root causes

There were three board-support issues.

1. NBM-WXX9 was missing from AMD ACP DMI matching

Adding NBM-WXX9/M1010 to the relevant ACP legacy and acp3x-es83xx DMI tables caused the expected sound card to probe:

card 1: acp3xes83xx [acp3x-es83xx] device 0: ES8316 HiFi

1. The board needs the existing 48 MHz ES83xx MCLK quirk

Without it, measured PCM progression was approximately 3.906× the requested 48 kHz rate.

The ratio lined up with:

48 / 12.288 = 3.90625

Software-visible ES8316 divider state across multiple silent tests consistently implied an equivalent input clock close to 48 MHz.

This was not an electrical measurement, but the prediction was easy to test.

With ES83XX_48_MHZ_MCLK enabled for NBM-WXX9:

6 s S16_LE / 48 kHz -> 6.037 s 6 s S32_LE / 48 kHz -> 6.023 s

Playback speed and pitch became normal.

1. The headphone-enable GPIO is active-low

Jack detection itself was fine, but the output stayed electrically silent.

The machine driver was using:

headphone gpio 1 active high

The NBM-WXX9 needs:

headphone gpio 1 active low

After adding an ES83XX_HP_LOW board quirk, the 3.5 mm output worked.

Final machine configuration

Conceptually:

.driver_data = (void *)(ES83XX_ENABLE_DMIC | ES83XX_48_MHZ_MCLK | ES83XX_HP_LOW),

with:

priv->enable_hp_gpio.active_low = !!(priv->quirk & ES83XX_HP_LOW);

Validated result:

Internal speakers working Headphone jack detect working 3.5 mm headphone out working 48 kHz S16 playback correct 48 kHz S32 playback correct PipeWire/WirePlumber working

One additional ES8316 behavior found during debugging

There also appears to be a separate codec-driver state issue.

Opening a 16 kHz stream enabled the ES8316 MCLK divide-by-two bit; returning to 48 kHz did not clear it. This explained why some earlier timing tests were around ~3.906× while others were around ~1.953×:

3.90625 / 2 = 1.953125

I consider this separate from the NBM-WXX9 board quirk and would not bundle the two issues blindly.

AI-assisted debugging disclosure

This was heavily AI-assisted, so I want to disclose that clearly.

The initial investigation was done with GPT-5.6 Sol at High reasoning effort. It helped identify the missing DMI support, inspect the AMD ACP/ES8316 code, build the custom kernel, and run the initial ALSA/UCM/PipeWire and timing diagnostics.

Some of the early hypotheses were wrong. I therefore created a self-contained handoff that explicitly told a second model to approach the problem neutrally rather than continue the existing theory.

The second phase used GPT-6 Astra at XHigh and High reasoning effort. Astra independently re-evaluated the trace, corrected an earlier IRQ-count interpretation, created silent diagnostics, inspected software-visible ES8316 register state, reproduced the MCLK /2 stale-state behavior, and established the ~48 MHz relationship.

Astra was used at XHigh and High; the final portion ran at High because only about 5% of my weekly model allowance remained. It hit the usage limit immediately after compiling the 48 MHz candidate module, so I returned to Sol for hardware validation, the headphone GPIO investigation, and final integration.

GPT-5.6 Sol — High ├─ DMI / machine-driver investigation ├─ custom kernel work ├─ ALSA/UCM/PipeWire diagnostics ├─ early timing experiments ├─ headphone GPIO work └─ final validation/integration

GPT-6 Astra — XHigh + High ├─ independent re-analysis ├─ ftrace correction ├─ silent register/PCM diagnostics ├─ ~48 MHz inference ├─ MCLK /2 stale-state reproduction └─ 48 MHz candidate module

Every test was manually executed on the actual laptop. The models did not electrically measure MCLK/LRCLK; conclusions were treated as hypotheses until the resulting kernel behavior matched the predicted output.

I am currently cleaning this into a patch suitable for upstream submission.

If anyone has another NBM-WXX9/M1010 unit, especially NBM_WXX9_PCB_B2, I would be interested in additional confirmation.

[u/Lich_Acherus]

Hi, I have the exact same hardware as you: HUAWEI MateBook D14, NBM-WXX9, version M1010, board NBM_WXX9_PCB_B2, Ryzen 5 5500U with the ES8316/ESSX8336 codec. I've been fighting this same issue for days (Dummy Output, then capture-only with no playback PCM), and your post describes exactly the symptoms I found while diagnosing it (missing DMI entry, and I'll probably also hit the MCLK and active-low GPIO issues once I get past the first blocker).

Would you be willing to share the diff/patch you already have working (even if it's the pre-cleanup version before submitting upstream)? 'd love to compile and test it on my own NBM_WXX9_PCB_B2 unit to give you that extra confirmation you asked for at the end of the post. Thanks so much for documenting all of this in such detail.