[Bug 2172674] Re: ES8336 codec audio stops after first stream (Hardware fails to wake up on Kernel 7.0.0)

Update (Suspend Trigger Identified): I wanted to add an update because I have isolated the exact trigger for this deadlock. After more testing, I can confirm this happens 100% of the time after the system enters auto-suspend (for example, after unplugging the laptop and leaving it idle). When the laptop wakes up, the hardware is completely wedged. dmesg shows PM: suspend exit right before the audio dies. Proposed Workaround: Since the deadlock is strictly triggered by the suspend/resume cycle, preventing the system from suspending entirely (via XFCE Power Manager) bypasses the bug—the hardware never loses power, so it never goes to sleep. I have applied this setting to both the AC and battery profiles and am currently running it successfully. This strongly suggests the failure happens when the kernel tries to wake the ES8336 codec back up. If the system does suspend, a full reboot remains the only way to recover the audio. I have updated the GitHub documentation linked in my original description to reflect this new finding. Thank you for looking into this. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2172674 Title: ES8336 codec audio stops after first stream (Hardware fails to wake up on Kernel 7.0.0) Status in linux package in Ubuntu: New Bug description: This is my first kernel bug report, so I apologize if my terminology isn't perfect, but I have done a lot of testing to isolate this issue. Hardware: Intel N95 Laptop (Dixmau brand), ES8336 Codec (ACPI ID: ESSX8336). OS: Xubuntu 26.04.1 LTS (Kernel 7.0.0). The Issue: On this kernel, the first audio stream after boot works perfectly. However, when that stream stops, the hardware goes into a sleep state and fails to wake up. The next audio stream is completely silent. The volume meters move, but no sound comes out. Only a full reboot fixes it. Historical Context (24.04.5 LTS): On the previous LTS, this hardware wasn't recognized at all out of the box (it only showed "Dummy Output"). I had to manually force the system to recognize the ES8336 card. Once forced, it worked perfectly across multiple streams. It seems the new kernel recognizes the card better, but the new power management is breaking it. The Evidence (Raw ALSA Test): To prove this wasn't just a PipeWire/software issue, I stopped the audio services entirely and used raw ALSA (speaker-test -D plughw:0,0). The test produced silence after the failure, proving the hardware is stuck at the kernel level, not in the user software. lsmod confirms the snd_soc_es8336 driver is loaded. The Workaround: To stop the hardware from sleeping and breaking, I run a silent audio stream in the background. Keeping the device "awake" prevents the deadlock: pacat --playback --device=alsa_output.pci-0000_00_1f.3-platform-sof-essx8336.stereo-fallback /dev/zero Full Transparency: I used an AI assistant to help me parse the terminal logs, understand the power-management issue and structure this description. The full, unedited debugging process, command history, and AI disclosure are documented here: https://github.com/abdellahi-beirouck/linux-audio-debugging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172674/+subscriptions