[BUG] sof_es8336: speaker amp GPIO stays off after stream stop/restart on Gemini Lake ES8336 (no sound until "Speaker Switch" is toggled) #5967

UPDATE: see the comment below with trace data (all occurrences are a STOP/START pair a few ms apart from the data thread on an open PCM, with no DAPM power cycle in between).

Describe the bug

On an Adreamer Leobook 13 laptop (Intel Gemini Lake, ES8336 codec on SSP2, sof-essx8336 machine driver) the internal speaker randomly goes silent, typically when a browser stops and restarts playback (YouTube ad transitions, pause/resume). While it is silent, the PCM is RUNNING and hw_ptr advances at 48 kHz, PipeWire reports no errors, the ALSA mixer is unchanged and nothing is logged in dmesg. Toggling "Speaker Switch" off and on restores the sound without closing the PCM.

The only difference I could find between the broken and the working state is the speaker enable GPIO (speakers-enable). Everything else I captured is identical: the full DAPM debugfs tree (including Speaker Power: On and Speaker: On), the ES8336 regmap registers, the ALSA mixer controls and the PCM status.

My analysis (a hypothesis supported by the data above, not a full trace): in sound/soc/intel/boards/sof_es8336.c, sof_8336_trigger() drives the speaker GPIO to the "off" level on PAUSE_PUSH, SUSPEND and STOP (to avoid pop noise) without updating priv->speaker_en, while the START, PAUSE_RELEASE and RESUME cases do nothing. The GPIO is only restored by sof_es8316_speaker_power_event() when DAPM really powers the "Speaker Power" supply down and up again. If the stream is stopped and started again without that full power cycle (pause/resume, xrun recovery, a restart within pmdown_time), nothing re-enables the amplifier: the GPIO stays off while DAPM still considers the speaker on. I have not determined which of these paths triggers it on my machine. Setting pmdown_time to 0 on the codec and BE links did not prevent the problem.

To Reproduce

1. Play videos with ads on YouTube in a browser (Chrome or Firefox).
2. Let ads start and stop, or pause and resume, over a period of time.
3. Eventually the speaker goes silent while the video keeps playing.

I could not trigger it on demand with a simple stress test (playing a short wav file with paplay 80 times with random 0-6 s pauses), so it seems to depend on how the browser and PipeWire stop and restart the stream.

Reproduction Rate

Intermittent. Before I worked around it: 15 occurrences in about 10 hours of use on one day.

Expected behavior

The speaker amplifier should be enabled whenever the stream is running and DAPM considers the speaker on.

Impact

Major annoyance: audio disappears several times per hour of normal use, and the only recovery is toggling "Speaker Switch" (or suspending and resuming the sink, or restarting the audio server).

Environment

• Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
  • Linux: Ubuntu kernel 6.8.0-139-generic (Linux Mint 22, upstream v6.8 base). The patched out-of-tree module was built from sound/soc/intel/boards/sof_es8336.c of upstream v6.8.
  • SOF firmware: Ubuntu package firmware-sof-signed 2023.12.1-1ubuntu1.11, intel/sof/sof-glk.ri (firmware version 2:2:0-57864, ABI 3:22:1, kernel ABI 3:23:0)
• Name of the topology file
  • Topology: intel/sof-tplg/sof-glk-es8336-ssp2.tplg
• Name of the platform(s) on which the bug is observed.
  • Platform: Intel Gemini Lake (Celeron/Pentium Silver, PCI 8086:3198), Adreamer Leobook 13 (board name PN1308P), ES8336 on SSP2 (quirk mask 0x2)
• Userspace: PipeWire 1.0.5, WirePlumber 0.4.17, alsa-ucm-conf 1.2.10-1ubuntu5.15 (UCM profile HiFi)

Screenshots or console output

/sys/kernel/debug/gpio in the two states:

broken:   gpio-541 (speakers-enable) out lo ACTIVE LOW
working:  gpio-541 (speakers-enable) out hi ACTIVE LOW

PCM status while broken, sampled 2 seconds apart: state: RUNNING, hw_ptr 14486976 -> 14583408 (96432 frames in about 2 s, i.e. 48 kHz). Speaker Switch was on.

Full captures (DAPM debugfs tree, ES8336 regmap registers and gpio) in the broken and in the working state are attached, plus their diff: audio-codec-fail.txt, audio-codec-ok.txt, audio-codec-diff.txt.

Proposed change (sketch, not a formal patch)

Re-enable the amplifier on resume when the driver believes it is on:

 case SNDRV_PCM_TRIGGER_START:
 case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 case SNDRV_PCM_TRIGGER_RESUME:
+        if (substream->stream == 0 && priv->speaker_en == false)
+                schedule_delayed_work(&priv->pcm_pop_work,
+                                      msecs_to_jiffies(70));
         break;

Test result with the change

I tested this change (plus an extra dev_info() message, printed only when the GPIO is found low on resume and no work is pending, to count occurrences), built out-of-tree and installed as a DKMS replacement for snd-soc-sof_es8336 on 6.8.0-139. In about 42 hours of YouTube and Netflix use it caught and fixed the condition 6 times, with no audible dropouts and no interventions from a userspace watchdog I kept running as a safety net (it polls the GPIO and toggles "Speaker Switch" when the PCM is RUNNING and the pin is low). Before loading the patched module, the same watchdog had to intervene 15 times in about 10 hours on one day.

From reading a recent mainline tree, sof_8336_trigger() looks unchanged there, but I have not tested mainline. I am happy to test other proposals, provide more traces, or turn this into a formal patch for linux-sound if the approach looks acceptable.

I also sent this report to linux-sound@vger.kernel.org and sound-open-firmware@alsa-project.org in early October 2026 (the first attempt was rejected because it had an HTML part, and it was resent as plain text).

audio-codec-ok.txt
audio-codec-fail.txt
audio-codec-diff.txt