Filing this for the GPD WIN 4 2025 (model G1618-04, Ryzen AI 9 HX 370, Realtek ALC245 codec), running CachyOS with the linux-cachyos-deckify kernel.
The built-in speakers are dead on every fresh boot. The whole audio stack looks totally fine - PipeWire/ALSA see the analog sink, the speaker port is active, nothing is muted, volume is up, the codec speaker pin is enabled with EAPD set. There's just no sound from the speakers. Headphones, Bluetooth and USB audio all work fine.
The one thing that fixes it: a suspend/resume. If I suspend (s2idle) and wake, the speakers work every single time, and stay working for the rest of that session. A cold boot never enables them.
I dug into this pretty hard and ruled a lot out. None of these enable the amp:
- codec re-init (reconfig) and full controller unbind/rebind
- replaying the exact codec verb sequence the kernel sends on resume
- toggling EAPD, vendor COEFs, GPIOs
- switching audio profiles/ports
- enabling codec power_save (it does reach D3cold, but that alone isn't enough)
- disabling Fast Boot in the BIOS
The codec registers come out byte-identical whether sound works or not, and every GPIO that changes between the dead and working state traces back to the touchscreen/peripherals, not audio. So as far as I can tell the speaker amp's power rail is controlled by the EC, and the EC only switches it on during a real S0i3 (s2idle) resume - it never does it at cold-boot POST. That would explain why only a suspend/resume works and nothing the OS can poke does.
My guess is the real fix is either a GPD BIOS/EC update (enable the amp at POST like it does on resume), or a kernel quirk that sends whatever EC command Windows uses - but I couldn't find that command from the Linux side.
For now I made a workaround: a small systemd service that does one ~1 second s2idle suspend/resume early in boot, before the greeter, while the screen is still black. It adds about a second to boot, you never see it, and audio is working by the time you reach game mode or the desktop. It's a hack, but it works reliably.
Repo with the service and an install script:
https://github.com/DevL0rd/GPD-WIN-4-Audio-Fix
Honestly not sure where to go from here - whether this should be a kernel quirk, a packaged workaround, or kicked to GPD for a firmware fix. Figured I'd share the findings and the workaround in case it helps someone else or someone knows the proper fix. Happy to test patches.
Filing this for the GPD WIN 4 2025 (model G1618-04, Ryzen AI 9 HX 370, Realtek ALC245 codec), running CachyOS with the linux-cachyos-deckify kernel.
The built-in speakers are dead on every fresh boot. The whole audio stack looks totally fine - PipeWire/ALSA see the analog sink, the speaker port is active, nothing is muted, volume is up, the codec speaker pin is enabled with EAPD set. There's just no sound from the speakers. Headphones, Bluetooth and USB audio all work fine.
The one thing that fixes it: a suspend/resume. If I suspend (s2idle) and wake, the speakers work every single time, and stay working for the rest of that session. A cold boot never enables them.
I dug into this pretty hard and ruled a lot out. None of these enable the amp:
The codec registers come out byte-identical whether sound works or not, and every GPIO that changes between the dead and working state traces back to the touchscreen/peripherals, not audio. So as far as I can tell the speaker amp's power rail is controlled by the EC, and the EC only switches it on during a real S0i3 (s2idle) resume - it never does it at cold-boot POST. That would explain why only a suspend/resume works and nothing the OS can poke does.
My guess is the real fix is either a GPD BIOS/EC update (enable the amp at POST like it does on resume), or a kernel quirk that sends whatever EC command Windows uses - but I couldn't find that command from the Linux side.
For now I made a workaround: a small systemd service that does one ~1 second s2idle suspend/resume early in boot, before the greeter, while the screen is still black. It adds about a second to boot, you never see it, and audio is working by the time you reach game mode or the desktop. It's a hack, but it works reliably.
Repo with the service and an install script:
https://github.com/DevL0rd/GPD-WIN-4-Audio-Fix
Honestly not sure where to go from here - whether this should be a kernel quirk, a packaged workaround, or kicked to GPD for a firmware fix. Figured I'd share the findings and the workaround in case it helps someone else or someone knows the proper fix. Happy to test patches.