After booting Mint, the headphone jack does not work. I have already ran the audio script.
Functional headphone jack, outputting audio.
Hey! I recently switched a HP chromebook model 14-ca023nr to linux mint as well. My board is “Snappy” and i was able to get my speakers working and my headphone jack. and the actual audio script didn’t correctly upload my audio drivers so i had top pull them from github directly. anyway, i had claude generate a guide for me bc im too lazy to explain it all too you but this is everything i did:
If you’re new to Linux, some of this will look intimidating. Here’s the short version of what’s actually going on, so the commands below make sense instead of feeling like magic spells:
Your Chromebook’s audio hardware is (usually) two separate chips: one for your headphone jack, and one for your built-in speakers. They’re controlled independently.
“Firmware” here does NOT mean your BIOS/coreboot. MrChromebox firmware is what lets your laptop boot at all — you are never touching that in this guide. The “firmware” we deal with here is just data files on your hard drive (in /usr/lib/firmware/) that tell your sound driver how to talk to the audio chips. Reinstalling these is as safe as reinstalling any other program.
Linux Mint is not officially supported on these converted Chromebooks. That means none of this works automatically — you have to manually walk the driver through several layers that a “supported” distro would handle for you.
There are basically four layers that all have to work for sound to come out:
The kernel driver (does Linux even recognize the chip exists?)
The firmware data files (does the driver have the data it needs to talk to the chip?)
PipeWire/PulseAudio (is the system actually sending audio to that device?)
The chip’s own internal hardware switches (is the audio path itself muted at a level neither of the above controls?)
If you skip straight to troubleshooting audio and something’s not working, it can be any one of these four — this guide checks them in order.
Don’t hand-edit files or copy things around manually — use the community tool built for this:
bash
sudo apt install -y git
git clone --depth 1 GitHub - WeirdTreeThing/chromebook-linux-audio: Script that enables audio support on many Chrome devices running various Linux distros · GitHub
cd chromebook-linux-audio
./setup-audio
What to expect:
It detects your CPU platform (e.g. “Intel Apollolake”) and your audio chips (e.g. da7219 for headphones, max98357a for speakers).
If your board has a max98357a speaker chip, you’ll get a serious-looking warning. This chip has no built-in volume limiter, so pushing it too loud can permanently damage your speakers. The script disables speakers by default to protect them. This warning is about speakers only — it does not affect your headphone jack. Only pass --force-avs-install if you’re deliberately choosing to risk your speakers.
If asked to choose a driver mode, pick AVS, not SOF — on these Intel Apollolake boards, SOF doesn’t support the headphone jack at all.
Reboot after it finishes:
bash
sudo reboot
bash
aplay -l
You want to see entries like:
card 1: avsda7219 [avs_da7219], device 1: Headset
If you see nothing at all (“List of PLAYBACK Hardware Devices” with nothing under it), the driver isn’t binding to your hardware. Check why:
bash
dmesg | grep -i avs
Look for lines like:
request topology “intel/avs/da7219-tplg.bin” failed: -2
or
invalid header size
This means the actual firmware data files your driver needs are missing or corrupted. Check what’s actually there:
bash
ls -la /usr/lib/firmware/intel/avs/
Warning signs:
Files missing entirely
Multiple files with the exact same byte size (a sign of an accidental duplicate, usually from an earlier manual “fix” attempt gone wrong)
Fix it by reinstalling the firmware package fresh:
bash
sudo rm -f /usr/lib/firmware/intel/avs/*-tplg.bin
sudo apt update
sudo apt install --reinstall linux-firmware
sudo reboot
If that doesn’t restore the files (Mint’s package sometimes just doesn’t ship them for these less-common chips), pull them straight from the source Linux itself uses:
bash
cd /tmp
git clone --depth 1 --filter=blob:none --sparse Making sure you're not a bot!
cd linux-firmware
git sparse-checkout set intel/avs
sudo mkdir -p /usr/lib/firmware/intel/avs
sudo cp intel/avs/*-tplg.bin /usr/lib/firmware/intel/avs/
sudo reboot
Run aplay -l again. You should now see your card(s) listed.
Even once Linux sees the hardware, your desktop’s sound system (PipeWire, which handles audio routing on Mint) might not be using it correctly.
Set the correct output profile:
Open pavucontrol (install with sudo apt install pavucontrol if you don’t have it)
Go to the Configuration tab
For each audio card listed, set the profile to Pro Audio (not “Off”)
Find your headphone device’s real internal name:
bash
pactl list sinks short
Look for something containing da7219 — e.g. alsa_output.platform-avs_da7219.2.pro-output-1
Set it as the default output:
bash
pactl set-default-sink alsa_output.platform-avs_da7219.2.pro-output-1
If something’s already playing, move it over manually:
bash
pactl list sink-inputs short
pactl move-sink-input alsa_output.platform-avs_da7219.2.pro-output-1
Known gotcha: the default output can silently reset back to your speakers after a reboot or a service restart. If sound seems to randomly “break” again later, check this first before assuming something’s actually wrong:
bash
pactl get-default-sink
This is the step almost nobody expects, and the one most likely to be your actual problem if you’ve done everything above and there’s still dead silence.
Your sound chip has its own internal mute switches that PipeWire’s “Pro Audio” profile does not touch — it assumes something else already turned them on, which often just doesn’t happen on an unsupported distro.
Find your card number first (from aplay -l, e.g. card 1), then check:
bash
amixer -c 1 contents | grep -B1 “values=off,off”
Two switches in particular are the common culprits:
Headphone Switch — mutes the headphone amp output itself
Playback Digital Switch — mutes the digital audio path upstream of that
Unmute both:
bash
amixer -c 1 set Headphone unmute
amixer -c 1 set ‘Playback Digital’ unmute
Confirm they flipped from off,off to on,on:
bash
amixer -c 1 contents | grep -A2 “Headphone Switch”
amixer -c 1 contents | grep -A2 “Playback Digital Switch”
Play something now and check. For most people, this single step is the actual fix — everything above can be 100% correctly configured, and audio will still be silent until these are flipped.
If it’s still silent, two more switches control whether the DAC even feeds into the output mixer stage at all:
bash
amixer -c 1 set ‘Mixer Out FilterL DACL’ unmute
amixer -c 1 set ‘Mixer Out FilterR DACR’ unmute
Test at the rawest possible level, completely bypassing PipeWire, to confirm whether the issue is software routing or something deeper:
bash
speaker-test -D hw:1,1 -c 2
(replace 1,1 with your actual card/device numbers from aplay -l)
If this produces clean pink noise/static with no errors, but you genuinely hear nothing through headphones even with every switch above unmuted — this may be an unresolved gap in how the AVS driver routes signal to the physical jack on your specific board (confirmed on the HP “Snappy” board, for example). In that case, the practical workaround is a cheap USB-C to 3.5mm audio adapter — it creates its own independent USB sound card and completely bypasses the broken internal jack.
Thank you! With help from Claude (haha), I was able to get things working. Thanks a ton for the reply!
In case there are people that are facing the same issues that I did, here is a summary from Claude that outlines what I did. Good luck!
Board tested: HP Chromebook x360 14c-cc0011cc (codename Eldrid), Linux Mint 22.3, sof-rt5682 codec.
If aplay -l already shows a working sof-rt5682 card with a Headset device, and PipeWire’s default sink is correctly set to the headset output, but you still get dead silence through the headphone jack — the kernel driver, firmware, and PipeWire routing are all fine. The problem is almost always hardware mute switches on the codec itself that Linux never turns on by default.
Find your card number from aplay -l (usually 0), then check the headphone-specific mixer controls:
amixer -c 0 contents | grep -A2 -i "hp"
Look for HPOL Playback Switch and HPOR Playback Switch (Headphone Out Left/Right). If both read values=off, that’s your bug. (Headphone Jack / Headphone Jack Switch reading on means jack detection is fine — this is a separate mute issue.)
Setting by name may silently no-op on this codec (ambiguous control names). Use cset with the numid instead — get the numid from the grep output above (e.g. numid=82 for HPOL, numid=83 for HPOR):
amixer -c 0 cset numid=82 on
amixer -c 0 cset numid=83 on
Confirm both flipped to on, then test audio.
The above doesn’t survive a reboot on its own:
sudo alsactl store
This saves mixer state to /var/lib/alsa/asound.state, restored automatically by the alsa-restore service on boot. Reboot once and re-check the switches to confirm.
pactl get-default-sink if sound “disappears” again later.cset commands.amixer -c 0 contents | grep -A2 "Spk Switch" (or search grep -i -E "spo|spk|speaker" for the exact control name on your codec) — same cset numid=X on + alsactl store fix applies.Test raw output bypassing PipeWire entirely: speaker-test -D hw:0,1 -c 2 (adjust card/device numbers to match aplay -l). If you get clean output but still hear nothing through the jack specifically, it may be an unresolved AVS/SOF signal-routing gap on your board — a cheap USB-C to 3.5mm adapter sidesteps it entirely.