[BUG] ALC295 internal speaker silent on Panasonic Let's Note CF-SV8 (PCI subsys 10f7:8338)

[BUG] ALC295 internal speaker silent on Panasonic Let's Note CF-SV8 (PCI subsys 10f7:8338)

[kay-ws]

Hi,

Internal speaker is silent on a Panasonic Let's Note CF-SV8-2
(Realtek ALC295, PCI subsystem 10f7:8338), while the headphone jack
works correctly.

Hardware confirmed healthy:
  - Internal speaker plays sound under Windows 10
  - Panasonic BIOS HW self-test reports speaker OK

Linux side:
  - Kernel 7.0.2-2-cachyos (CachyOS / Arch)
  - ALSA 1.2.15.2, PipeWire 1.6.4

The driver picks no quirk fixup for this subsys:

  ALC295: picked fixup  for PCI SSID 10f7:8338   <- empty fixup name

PCM data reaches Pin 0x14 (Audio Output 0x02 has stream=1 during
playback, same as 0x03 which feeds the working headphone), Pin-ctls
is OUT, amp is unmuted, but no audio is produced through the
internal speaker.

Tried with no effect:
  - options snd_hda_intel model=thinkpad (fixup chain runs)
  - hda-verb 0x14 SET_EAPD_BTLENABLE 0x02
  - hda-verb 0x01 SET_GPIO_MASK/DIRECTION/DATA 0x03
  - WirePlumber profile output:analog-stereo (non-duplex)

Full alsa-info.sh dump:
  http://alsa-project.org/db/?f=546e2c9fc0e2261cb6d8a7c837f8c3f54f771064

Could a fixup entry for PCI SSID 10f7:8338 be added to the alc269
quirk table? I'm happy to test patches and try Realtek coef
sequences if suggested.

Thanks,
kay-ws

Re: [BUG] ALC295 internal speaker silent on Panasonic Let's Note CF-SV8 (PCI subsys 10f7:8338)

[Kay]

Closing the loop on this bug report for the list archive.

The root cause turned out to lie entirely outside the ALSA driver. The
codec layer (snd_hda_codec_realtek) was correct all along; no kernel
fixup or patch is needed for this hardware. The actual issue was a
combination of (1) an older BIOS that left the ALC295 codec in a state
that could not drive the internal speaker amplifier at all, and (2) a
userspace ACP path config that unconditionally mutes the speaker mixer
control on every path activation.

(1) BIOS
-------

Panasonic shipped a BIOS update for this model (V2.00L30, dated
2025-06-19) via Windows Update. After applying it, the ALC295 codec
initializes correctly. The "Speaker Playback Switch" then behaves as a
normal Pin 0x14 Amp-Out mute bit, and toggling it on lets audio flow
through the internal speaker as expected.

For others hitting the same symptom on Panasonic Let's Note CF-SV8: a
BIOS update via Windows Update resolved the codec-side issue here, with
no kernel changes required. Older BIOS versions appear to leave the
codec in a state from which the internal speaker cannot be unmuted at
all, even with manual hda-verb writes to Pin 0x14.

(2) Persistence (PipeWire / ACP path config)
-------------------------------------------

After the BIOS fix, the speaker could be unmuted with
`amixer sset Speaker on`, but the "Speaker Playback Switch" was reset
to off on every wireplumber restart and on every boot, leaving the
speaker silent again until manually unmuted.

The cause is in the ACP path config file
/usr/share/alsa-card-profile/mixer/paths/analog-output-speaker.conf,
specifically:

    [Element Speaker]
    required-any = any
    switch = off
    volume = merge

The "switch = off" directive instructs ACP to "always set this control
to off" whenever this path is activated. This config assumes a
classical HD-Audio layout where Master is the master attenuator/mute
and Speaker is a path-selection hint that should be left off. On
ALC295, however, "Speaker" is the per-pin (Pin 0x14) Amp-Out mute bit
of the internal speaker, and Master alone does not gate it. The
unconditional "switch = off" therefore mutes the internal speaker on
every path activation.

Workaround: drop a copy of analog-output-speaker.conf into
/etc/alsa-card-profile/mixer/paths/ and change the [Element Speaker]
directive to "switch = ignore":

    [Element Speaker]
    required-any = any
-   switch = off
+   switch = ignore
    volume = merge

PipeWire's ACP picks up the /etc/ copy in preference to the one under
/usr/share/. After this change, ACP no longer touches the Speaker mixer
control on path activation, the speaker stays unmuted across
wireplumber restarts, warm reboots, and cold boots (including a full
battery-out power cycle), and no other userspace component
(alsa-restore.service, autostart scripts, custom systemd units) is
needed to keep it that way.

Thanks to the list -- lore archives of similar codec quirks were
useful while triaging this.

--
kay-ws