Re: [BUG] ALC285 + CS35L56 (ASUS ROG Zephyrus G14 2025, GA403WR, SSID 1043:1024), no speaker output despite correct routing, gain, and DSP state

On 28/07/2026 1:57 pm, Aditya Sharma wrote:
> Hi,
> 
> I'm seeing complete silence from the built-in speakers on an ASUS ROG
> Zephyrus G14 2025 (GA403WR), despite every layer of the audio signal chain
> checking out correct on inspection. Headphones work perfectly. The same
> physical hardware produces normal speaker output under Windows (dual-boot),
> which rules out a hardware fault.
> 
> *Hardware:*
> 
>     - ASUS ROG Zephyrus G14 2025, GA403WR_GA403WR, BIOS GA403WR.309
>     - Realtek ALC285 codec, PCI SSID 1043:1024
>     - 2x Cirrus Logic CS35L56 amplifiers (i2c-CSC3556:00-cs35l56-hda.0/.1)
> 
> *Kernel:* 7.1.5-1-cachyos (CachyOS, based on stable v7.1.5)
> 
> *What I've verified, in order, all confirmed correct:*
> 
>     1. *Kernel quirk applies correctly.* ALC285_FIXUP_ASUS_GA403U_HEADSET_MIC
>     is present in the fixup table for SSID 1043:1024 and its chained
>     alc285_fixup_speaker2_to_dac1 executes — confirmed via
>     /proc/asound/card2/codec#0, Node 0x17 connection list shows 0x02*
>     selected (the expected DAC1 override), matching what the fixup function
>     sets. (Note: the "picked fixup [blank] for PCI SSID" dmesg line is
>     misleading — the fixup name is only populated with
>     CONFIG_SND_DEBUG_VERBOSE, which is off by default; the fixup ID itself
>     is still applied regardless.)
>     2. *EAPD correctly asserted* on both speaker pins (0x14, 0x1b) —
>     confirmed via hda-verb ... GET_EAPD_BTLENABLE returning 0x2.
>     3. *No amp faults logged* — dmesg | grep cs35l56 shows clean firmware
>     load, no fault/error/protect/thermal messages.
>     4. *CS35L56 DSP firmware fully operational on both amps* — via debugfs (
>     /sys/kernel/debug/sound/i2c-CSC3556:00-cs35l56-hda.{0,1}/DSP1/): booted=Y,
>     running=Y, hibernating=N, fw_id=0x001a00d6, fw_version=0x00030b10.
>     5. *Hardware-strapped speaker ID correctly detected* as spkid0 (read
>     from onchip GPIO straps per cs35l56_read_onchip_spkid()), and the
>     matching tuning files (cs35l56-b0-dsp1-misc-10431024-spkid0*) load
>     without error.
>     6. *PCM stream actively running* — /proc/asound/card2/pcm0p/sub0/status
>     shows state: RUNNING with moving hw_ptr/appl_ptr during speaker-test.
>     7. *DAC-level gain register confirmed at full scale* — Node 0x02
>     (Speaker Playback Volume): Amp-Out vals: [0x57 0x57] (max, 0dB), after
>     setting via amixer. ALSA-level Speaker, Master, Bass Speaker mixer
>     controls all unmuted at 100%. AMP1/AMP2 Speaker DSP-side gain controls
>     also confirmed at 85% (-4.75dB), non-zero.
> 
> Despite all of the above, no audible output whatsoever from the internal
> speakers. Headphones (Node 0x21) work normally at all volume levels.
> 
> Full alsa-info.sh dump (codec proc dump, amixer state, dmesg, alsactl
> state) is here:
> https://alsa-project.org/db/?f=cc6c08116d9a9c466039679d2142d0df1c12fa77
> 
> Given that routing, EAPD, DSP state, hardware ID, and gain all check out
> correct at every layer I can inspect from userspace, but Windows produces
> correct output on the same hardware, I suspect there's an initialization
> step or register sequence the Linux driver isn't replicating that Windows'
> Cirrus driver performs — possibly something not exposed via the standard
> ALSA controls (an additional calibration/init step, a missed I2C write
> sequence, or something specific to this board's implementation of the
> two-amp DAC1-shared configuration).
> 
> Happy to test patches, pull additional debugfs/regmap dumps, or compare
> against a Windows-side driver trace if that would help narrow this down.
> 
> Thanks,
> Aditya :]
> 

Your alsa-info.sh dump shows that speaker output is muted.

Simple mixer control 'Speaker',0
   Capabilities: pvolume pswitch
   Playback channels: Front Left - Front Right
   Limits: Playback 0 - 87
   Mono:
   Front Left: Playback 0 [0%] [-65.25dB] [on]
   Front Right: Playback 0 [0%] [-65.25dB] [on]