Guides on this site

Site Feedback
1

I just found this site after spending many hours in the terminal fixing my audio and heaphone jack on linux mint. On this site i’ve seen a LOT of mint users struggling with heaphone jacks and audio. in turn i made a full guide to troubleshooting because mint actually mutes drivers and mixes up names in its audio manager. But infortunantly theres no good way for me to post a guide on this site. and going and replying to every single person who has an audio problem is exhausting… thanks for listening. PS here’s my guide… and if there is a way to post guides and i just didn’t know im so sorry!

Fixing Audio on a MrChromebox-Converted Chromebook (Linux Mint) — Full Guide

Before you start: a few things explained

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:

    1. The kernel driver (does Linux even recognize the chip exists?)

    2. The firmware data files (does the driver have the data it needs to talk to the chip?)

    3. PipeWire/PulseAudio (is the system actually sending audio to that device?)

    4. 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.

Step 1: Install the driver properly

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 https://github.com/WeirdTreeThing/chromebook-linux-audio
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

Step 2: Check if the driver actually loaded

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 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
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.

Step 3: Make sure the system is actually sending audio to the right device

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:

  1. Open pavucontrol (install with sudo apt install pavucontrol if you don’t have it)

  2. Go to the Configuration tab

  3. 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 <id-number-from-above> alsa_output.platform-avs_da7219.2.pro-output-1

:warning: 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

Step 4: The hidden hardware mute switches (often the actual fix)

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

Step 5: If nothing above works

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.