Skip to content

No sound from internal speakers under SOF on ASUS Vivobook K6602ZC (ALC294 + CS35L41 SPI amp never initialised) #5937

Description

@jmehami1

Summary

On the ASUS Vivobook K6602ZC (Alder Lake-P, ALC294 + CS35L41 SPI amps), the internal speakers produce no sound under the SOF driver (skl_hda_dsp_generic machine driver / sof-hda-generic-4ch.tplg topology), while the internal digital microphone array only works under SOF. Forcing the legacy snd_hda_intel driver (options snd-intel-dspcfg dsp_driver=1) makes the speakers work correctly, because snd-hda-scodec-cs35l41-spi attaches and initialises the amps in that path — but the internal mic (PCH DMIC array) is then unreachable. There appears to be no configuration on current kernels that gets both working at once, because the CS35L41 SPI-amp fixup that the Realtek codec quirk table applies under the legacy driver is never triggered when the codec runs under SOF's hdac_hda bridge.

System

  • Machine: ASUS Vivobook K6602ZC (Vivobook_ASUSLaptopK6602ZC_K6602ZC-1.0-K6602ZC), Alder Lake-P
  • OS: Ubuntu 24.04.4 LTS (noble)
  • Kernels tested (all reproduce the issue under SOF): 7.0.0-31-generic, 6.17.0-40-generic, 6.14.0-37-generic, 6.17.0-1032-oem
  • Audio controller: 0000:00:1f.3 Intel Alder Lake PCH-P HD Audio Controller (8086:51c8)
  • Codec: Realtek ALC294, Vendor ID 0x10ec0294, Subsystem/SSID 0x1043,0x13d3
  • Speaker amps: 2x Cirrus Logic CS35L41 on SPI, ACPI device CSC3551, path \_SB_.PC00.SPI0.SPK1
  • sof-firmware/firmware-sof-signed 2023.12.1-1ubuntu1.11, alsa-ucm-conf 1.2.10-1ubuntu5.14

Expected behaviour

Internal speakers (via CS35L41) and internal microphone array (PCH DMIC) both work simultaneously under SOF, as they do in Windows via the vendor driver.

Actual behaviour

  • Under SOF (default): internal DMIC array works fine. Internal speakers are completely silent. The codec speaker pin, DAC, mixer levels, and PCM state all look correct — the mute is downstream, in the un-initialised CS35L41 amp.
  • Under legacy (dsp_driver=1, snd_hda_intel bound): snd-hda-scodec-cs35l41-spi attaches, amps initialise, speakers work correctly at normal volume. Internal DMIC array is not exposed at all (every non-jack input pin on the codec reports Pin Default 0x411111f0 = not connected — there is no analog path to the internal mics without the DSP).
  • Under AVS (dsp_driver=4): fails entirely — snd_soc_avs 0000:00:1f.3: Direct firmware load for intel/avs/adl/dsp_basefw.bin failed with error -2. No sound card is created at all (linux-firmware's intel/avs/ tree only ships firmware for Skylake-class parts, nothing for adl).

Diagnostic detail (captured under SOF)

dmesg at SOF probe:
sof-audio-pci-intel-tgl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware file: intel/sof/sof-adl.ri
sof-audio-pci-intel-tgl 0000:00:1f.3: Topology file: intel/sof-tplg/sof-hda-generic-4ch.tplg
snd_hda_codec_alc269 ehdaudio0D0: ALC294: picked fixup (pin match)
snd_hda_codec_alc269 ehdaudio0D0: autoconfig for ALC294: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
snd_hda_codec_alc269 ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
snd_hda_codec_alc269 ehdaudio0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0)

"picked fixup (pin match)" has an empty fixup name — no SSID-specific quirk matched, so the codec falls back to a generic pin-based fixup. No cs35l41, scodec, or CSC3551 string appears anywhere in the boot log, and no snd_hda_scodec_cs35l41* module ever loads — the CS35L41 SPI-amp fixup path that patch_realtek.c provides for other ASUS SSIDs is never reached for 0x1043,0x13d3 when the codec is bridged through SOF's hdac_hda.

alsa.components (also missing any cs35l41 component):
HDA:8086281c,80860101,00100000 HDA:10ec0294,104313d3,00100004 cfg-dmics:4

Codec state while a test tone is actively playing, confirming digital audio does reach the codec/DAC and the codec-side speaker path is fully open — the amp itself is simply never powered on:
Node 0x02 [Audio Output] ... Converter: stream=1, channel=0 # HP DAC, active
Node 0x03 [Audio Output] ... Converter: stream=1, channel=0 # Speaker DAC, active
Node 0x17 [Pin Complex] Speaker at Int N/A
Amp-Out vals: [0x00 0x00] # unmuted
Pin-ctls: 0x40: OUT # output enabled
EAPD 0x2: EAPD # EAPD on
Pin Default 0x90170110: [Fixed] Speaker at Int N/A

"Speaker Playback Switch"/"Speaker Playback Volume" are unmuted and non-zero; Auto-Mute Mode is Disabled; Headphone Jack reads off (nothing plugged in), so there's no false auto-mute routing either. Raising the SOF pipeline gain controls (PGA1.0, PGA7.0, PGA8.0, PGA9.0 "Master") made no difference.

ACPI confirms the amp is present but nothing binds to it:
$ ls /sys/bus/acpi/devices/ | grep CSC
CSC3551:00
$ cat /sys/bus/acpi/devices/CSC3551:00/path
SB.PC00.SPI0.SPK1

/sys/bus/spi/devices/ shows only the SPI-NOR flash (spi0.0) — no CS35L41 SPI device is ever instantiated under SOF.

What was already ruled out

  • Codec mute/volume/port/jack state (all correct, see above)
  • SOF pipeline gain (PGA*.0 Master controls) — raised them, no change
  • Vendor-specific ALC294 coefficient writes via hda-verb, reverse-engineered for a sibling model (Vivobook K6500Z, see https://github.com/goldarte/alc294_soundfix) — no effect, since the mute is in the Cirrus amp, not the Realtek codec
  • 4 different kernels (7.0.0-31-generic, 6.17.0-40-generic, 6.14.0-37-generic, 6.17.0-1032-oem) — identical behaviour on all
  • AVS driver (dsp_driver=4) as an alternative to SOF — fails outright due to missing intel/avs/adl/dsp_basefw.bin firmware in linux-firmware

alsa-info.sh output

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

(Captured under the legacy snd_hda_intel driver — i.e. the working-speakers/no-mic config. Codec/ACPI/hardware IDs in it are unaffected by which driver is bound. Happy to capture a second one from the SOF state on request.)

Ask

Could a machine-driver/quirk mapping be added so that skl_hda_dsp_generic (or whichever SOF machine driver claims this SSID) triggers the CS35L41 SPI-amp fixup for ASUS SSID 0x1043,0x13d3 (K6602ZC), the way patch_realtek.c already does for the legacy HDA path? Happy to test patches or provide additional dumps on request.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions