[BUG] ASUS Vivobook S 14 S5406SA (Lunar Lake, ALC294, SSID 1043:10c4): internal speakers gated ~1 Hz; 3.5mm headphone jack outputs only low-frequency thumping

[HT0710]

Summary

On an ASUS Vivobook S 14 S5406SA (Intel Lunar Lake-M, Realtek ALC294, SSID 1043:10c4),
all internal analog outputs are unusable under SOF:

• Internal speakers: audio gates on/off roughly once per second, both channels
  together, at any volume, across all applications.
• 3.5mm headphone jack: no intelligible audio; only a rhythmic low-frequency
  thumping is audible.

A USB audio adapter (UGREEN CM720) works perfectly, and Windows 11 on the same machine
drives both the internal speakers and the 3.5mm jack correctly. The problem reproduces
on a clean Ubuntu live USB, so it is not local configuration.

There is currently no quirk entry for SSID 1043:10c4; the codec falls back to generic
autoconfig.

Hardware / software

Model	ASUS Vivobook S 14 S5406SA_Q423SA
BIOS	S5406SA.330
Platform	Intel Lunar Lake-M, HD Audio Controller 8086:a828 (rev 10)
Codec	Realtek ALC294, Vendor 0x10ec0294, Subsystem 0x104310c4, Revision 0x100004
PCI SSID	1043:10c4 (ASUSTeK)
Driver	sof-audio-pci-intel-lnl
Distro	Ubuntu 26.04.1 LTS
Kernel	7.2.3-070203-generic (mainline); also 7.0.0-30 and 7.0.0-31 (Ubuntu)
firmware-sof-signed	2025.12.2-1
alsa-ucm-conf	1.2.15.3-1ubuntu1.5
PipeWire / WirePlumber	1.6.2 / 0.5.13

Reproduction

1. Boot the machine with the stock SOF driver.
2. Play any continuous audio (music, a video) through the internal speakers.
3. Audio gates on and off roughly once per second, both channels simultaneously.
4. Plug headphones into the 3.5mm jack; only low-frequency thumping is audible.

Key finding: Headphone Playback Switch gates the internal speakers

The internal speakers can be made to play correctly by unmuting the Headphone control:

amixer -c0 sset Headphone unmute

Speaker Playback Switch is on throughout — it is never the muted control. Captured
from /var/lib/alsa/asound.state while the speakers were silent:

name 'Headphone Playback Switch'   value.0 false   value.1 false
name 'Speaker Playback Switch'     value.0 true    value.1 true

So the ALSA control nominally scoped to the headphone pin also gates the internal
speaker path. The two pins draw from the same DAC pair:

Node 0x17 [Pin Complex] Pin Default 0x90170110: [Fixed] Speaker at Int
  Connection: 3 -> 0x02 0x03* 0x06
Node 0x21 [Pin Complex] Pin Default 0x03211020: [Jack] HP Out at Ext Left
  Connection: 2 -> 0x02* 0x03
  Control: name="Headphone Playback Switch", index=0, device=0

The workaround is not durable: any jack plug/unplug event re-mutes
Headphone Playback Switch, silencing the speakers again until it is unmuted manually.

The digital path is clean — the fault is after the DSP

Playing a synthetic 440 Hz tone through the speaker sink and recording that sink's
monitor gives a continuous, full-amplitude signal with no dropouts:

duration 6.14s  peak=12000
silent windows: 0/122

During the same playback:

• pw-top reports ERR 0 (no xruns), including with all 8 CPU cores saturated.
• The DSP stays runtime_status = active for the whole stream.
• /proc/asound/card0/pcm0p/sub0/status stays state: RUNNING.
• ALSA hw_ptr/appl_ptr progression is nominal (ratios 0.98–1.02).

Audio therefore reaches the DSP intact and is lost somewhere after it, in the analog
output stage shared by both internal outputs.

Codec autoconfig

The kernel applies no fixup and produces a generic configuration:

snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC294: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
snd_hda_codec_alc269 hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
snd_hda_codec_alc269 hdaudioC0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
snd_hda_codec_alc269 hdaudioC0D0:    mono: mono_out=0x0

Relevant pin state during playback (headphones connected, Headphone Jack reads on):

Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]          # unmuted (this pin is mute-only, no gain steps)
  Pincap 0x0001001c: OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x03211020: [Jack] HP Out at Ext Left
  Pin-ctls: 0xc0: OUT HP              # output enabled, HP amp enabled

Pin configuration, EAPD, and jack detection all appear correct while the jack still
produces only thumping.

Eliminated

Variable	Tested	Result
Kernel	7.0.0-30, 7.0.0-31, mainline 7.2.3	identical on all three
Topology	sof-hda-generic, sof-hda-generic-ace3-2ch, sof-hda-generic-ace3-4ch	no change (4ch broke the DMIC pipeline)
Driver	SOF, and legacy HDA via snd-intel-dspcfg dsp_driver=1	legacy HDA loaded cleanly as HDA Intel PCH but made both outputs worse
Userspace	direct ALSA plughw:0,0, bypassing PipeWire	still gates
Clean system	Ubuntu live USB	reproduces
Windows 11	same hardware	speakers and 3.5mm jack both correct
RT scheduling	data-loop.0 at rtprio 88, SCHED_FIFO	correct, no effect
Power management	snd_hda_intel power_save=0; DSP runtime_status sampled during playback	stays active, no effect
Memory pressure	no zram, zswap disabled, swap unused, PSI 0.00	not a factor
DSP DRC	Post Mixer Analog Playback DRC switch	already off
Persistent state	cleared asound.state and WirePlumber state, regenerated from defaults	no change

Per thesofproject/sof#10726,
hdajackretask, hda-verb, and /lib/firmware/*.fw patch files do not apply on the
SOF/IPC4 stack, so those were not pursued as fixes.

Related reports

• thesofproject/sof#10726 — ASUS VivoBook 14 Flip, Lunar Lake, ALC294, SSID 1043:10a4 (sibling model; mic rather than output).
• thesofproject/linux#5757 — HP OmniBook Ultra, Lunar Lake, headphone jack fails under SOF; dsp_driver=1 helps there but not on this machine.
• Arch Linux Forums thread 311966 — another ASUS Vivobook, Lunar Lake, ALC294, sof-audio-pci-intel-lnl: audio cutting out and cracking through headphones. Same symptom pair as this report; the Headphone-unmute workaround for the speakers originates there.

alsa-info

https://alsa-project.org/db/?f=4c774158aba9a2c95263b30b311eceb61dd7b6f5

Notes

Happy to test patches, capture additional traces, or provide a full alsa-info.sh dump
and codec dump on request.