Headphones not detected at boot on Linux Mint
On my ThinkStation P520, headphones plugged in before boot stayed silent until I unplugged and replugged them. The fix was one line in modprobe.d disabling HDA power saving.
On my Lenovo ThinkStation P520 running Linux Mint, I had an annoying audio bug: if I left headphones plugged in and booted the machine, they would not work. Unplug, replug, and audio came back immediately. Every time.
The Problem
Headphone jack detection on HD Audio systems works through jack sensing. The audio codec (often a Realtek chip on the motherboard) reports whether something is plugged into the headphone port. ALSA reads that state and routes audio to the right output.
On some systems — especially certain Lenovo workstations — the codec can end up in a bad state during boot:
- The audio driver initializes.
- The codec may enter a low-power state or otherwise fail to report its initial jack status correctly.
- The initial jack status is read incorrectly.
- ALSA thinks nothing is plugged in and routes audio to speakers (or nowhere useful).
When you physically unplug and replug the headphones, the codec fires a jack insertion event. ALSA updates its state and audio works. We just force a fresh jack-detection event.
The Fix
1
options snd_hda_intel power_save=0
That changes the behavior of snd_hda_intel, the ALSA kernel driver for most Intel/Realtek HD Audio chipsets.
power_save controls runtime power management on the codec:
0— disable power saving (codec stays awake)1,10, etc. — power down the codec after that many seconds of inactivity
With power_save=0, the codec stays fully initialized, jack detection stays active, and the boot-time jack status is much more likely to be read correctly.
The filename alsa-headphone-fix.conf has no special meaning. Modprobe reads every .conf file in /etc/modprobe.d/.
My hardware
My P520 exposes a single Intel HDA controller with two Realtek codecs attached:
1
cat /proc/asound/card*/codec* | grep Codec
1
2
3
Codec: Realtek ALC662 rev3
Codec: Realtek ALC233
Codec: Nvidia GPU 84 HDMI/DP
1
aplay -l
1
2
3
4
card 0: PCH [HDA Intel PCH], device 0: ALC662 rev3 Analog [ALC662 rev3 Analog]
card 0: PCH [HDA Intel PCH], device 4: ALC233 Analog [ALC233 Analog]
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [PHL 276E7]
...
ALSA identifies the machine as HDAudio-Lenovo-DualCodecs — Lenovo wired two codecs to the same controller. A typical workstation layout is ALC662 for rear-panel audio and ALC233 for the front headset jack, although I have not verified the exact wiring on this system. The NVIDIA codec is only for HDMI/DisplayPort and is unrelated to the headphone issue.
power_save=0 applies to the whole HDA controller, so both Realtek codecs stay awake. That avoids a race where one codec has not fully initialized when ALSA reads jack state at boot.
Verify it
Check that the parameter is active:
1
cat /sys/module/snd_hda_intel/parameters/power_save
Should output 0.
You can also check:
1
cat /sys/module/snd_hda_intel/parameters/power_save_controller
Typical output after the fix: Y.
Conclusion
This is not a glamorous fix — it is a one-line workaround for a timing bug between Realtek jack sensing, dual-codec topology, and HDA runtime power management. Realtek HD Audio codecs have accumulated plenty of Linux workaround reports over the years.
If your headphones only work after an unplug/replug cycle at boot, try disabling HDA power saving before chasing pin configs or PulseAudio/PipeWire settings. On my P520 it was the whole problem.