Summary
On an HP Spectre x360 13-ap0xxx (PCI audio ID 8086:9dc8, codec Realtek ALC285, SSID 103c:8514), the internal speaker produces no audio at all, while the 3.5mm headphone jack on the same codec works correctly. This suggests the fault is isolated to the internal-speaker output path (external amp and/or DSP routing), not the codec/DAC in general.
System
- Laptop: HP Spectre x360 Convertible 13-ap0xxx (
board_name reports 8514)
- Kernel: 7.0.0-28-generic (Ubuntu 26.04)
- Driver in use:
sof-audio-pci-intel-cnl, machine driver skl_hda_dsp_generic
- Firmware:
intel/sof/sof-cnl.ri (ABI 3:22:1)
- Topology loaded:
intel/sof-tplg/sof-hda-generic-2ch.tplg (generic fallback, not model-specific)
- Codec: Realtek ALC285 (
snd_hda_codec_alc269 module), Subsystem ID 0x103c8514
What works
- Headphones via the 3.5mm jack: full audio, confirmed working.
speaker-test completes with no errors (exit 0) routed to the internal speaker, but nothing is audible.
What I've ruled out
- Not a mute/volume issue:
Speaker Playback Switch = on, Speaker simple control = 95% ([-3.00dB], on), pin 0x17 amp value unmuted.
- Codec-level pin config for 0x17 looks correct and unambiguous:
Node 0x17 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
Pin Default 0x90170110: [Fixed] Speaker at Int N/A
Pin-ctls: 0x40: OUT
Connection: 3
0x02 0x03* 0x06 (selected: 0x03, the Speaker DAC/amp node, gain 0x53/0x53 — not zero)
- Codec GPIO block (
io=3) shows all GPIO pins unconfigured (enable=0 on all), for what it's worth — no GPIO-based amp-enable sequence appears to be active, though I can't confirm whether this model needs one.
- Not an ASoC/PipeWire routing issue at the "profile" level —
pactl shows the correct card/profile with a Speaker port active.
Possibly related, unconfirmed
dmesg shows:
snd_hda_codec_alc269 ehdaudio0D0: ALC285: picked fixup for PCI SSID 103c:0000
i.e. the fixup-matching code appears to read the SSID as 103c:0000 instead of the real 103c:8514 (confirmed via lspci -vv and /proc/asound/card0/codec#0, both of which report the correct 103c8514). This looks like the same symptom reported in #5819 (HP OMEN 16-ap0xxx, ALC245) — but I want to flag explicitly that in that issue the speakers work fine despite the same "SSID 0000" log line, so I'm not confident this is the actual cause of my silent speaker rather than a red herring / a separate, largely benign detection quirk on HP hardware. Filing this in case a maintainer recognizes whether a device-specific quirk/topology for SSID 103c:8514 exists or is planned, and whether the SSID-read issue is worth fixing independently.
Ask
- Is there a known device-specific SOF topology or ALC285 fixup for HP Spectre x360 13-ap0xxx (SSID
103c:8514)?
- Any pointers on how to determine whether this specific model requires a GPIO-driven external amp-enable sequence, and how to identify the correct GPIO/ACPI method if so?
Happy to gather more logs (sof-logger, full alsa-info.sh dump, ACPI tables) on request.
Summary
On an HP Spectre x360 13-ap0xxx (PCI audio ID
8086:9dc8, codec Realtek ALC285, SSID103c:8514), the internal speaker produces no audio at all, while the 3.5mm headphone jack on the same codec works correctly. This suggests the fault is isolated to the internal-speaker output path (external amp and/or DSP routing), not the codec/DAC in general.System
board_namereports8514)sof-audio-pci-intel-cnl, machine driverskl_hda_dsp_genericintel/sof/sof-cnl.ri(ABI 3:22:1)intel/sof-tplg/sof-hda-generic-2ch.tplg(generic fallback, not model-specific)snd_hda_codec_alc269module), Subsystem ID0x103c8514What works
speaker-testcompletes with no errors (exit 0) routed to the internal speaker, but nothing is audible.What I've ruled out
Speaker Playback Switch= on,Speakersimple control = 95% ([-3.00dB], on), pin 0x17 amp value unmuted.io=3) shows all GPIO pins unconfigured (enable=0on all), for what it's worth — no GPIO-based amp-enable sequence appears to be active, though I can't confirm whether this model needs one.pactlshows the correct card/profile with aSpeakerport active.Possibly related, unconfirmed
dmesg shows:
i.e. the fixup-matching code appears to read the SSID as
103c:0000instead of the real103c:8514(confirmed vialspci -vvand/proc/asound/card0/codec#0, both of which report the correct103c8514). This looks like the same symptom reported in #5819 (HP OMEN 16-ap0xxx, ALC245) — but I want to flag explicitly that in that issue the speakers work fine despite the same "SSID 0000" log line, so I'm not confident this is the actual cause of my silent speaker rather than a red herring / a separate, largely benign detection quirk on HP hardware. Filing this in case a maintainer recognizes whether a device-specific quirk/topology for SSID103c:8514exists or is planned, and whether the SSID-read issue is worth fixing independently.Ask
103c:8514)?Happy to gather more logs (
sof-logger, fullalsa-info.shdump, ACPI tables) on request.