Thanks for taking the time to respond. Cachy is my first Arch based distro and my second overall (after Kubuntu) and I’ve been using it since last November (following the end of security support for windows 10)
I did the research I could and tried the usual assortment of solutions and fixes (Alsamixer, pavucontrol tests, assigning defaults, etc.) The situation was caused by plugging in my wired headphone/microphone and unplugging it, things behaved normally before then for days and I hadn’t done any changes or updates for several days before the problem began. I had hoped a system update would fix things but it did not.
Before using the AI I tried both booting from USB and using the LTS version 6.18 of the kernel.
The USB live version functioned correctly. The LTS version of the kernel did not.
Getting things running again took several hours where many different approaches were tried, and so not every step along the way was necessarily relevant. I’ll be better the next time when it comes to documenting each step, but because it happened rather suddenly with no unusual actions leading up to the problem emerging I was expecting just a small setting I’d accidentally triggered to be the issue rather than a full audio driver collapse.
Once I started though, I didn’t want to lose the chat session and all my progress, so I pushed through until the end. After each stage I tested audio, rebooted, and then test audio again.
_________________________________________________________________________
Here’s the full summary of steps taken:
Used computer as normal for about half a day with audio functioning normally. After plugging in my headphones and joining a voice chat on discord I noticed the audio was incredibly difficult to hear. I exited the call, unplugged the headphones, and tested the computer audio to find that it wasn’t working.
I tried basic fixes first. System upgrade to see if this was the usual sort of small arch breaking that updating and rebooting would fix. No luck.
I checked KDE’s sound options, adjusting it changed nothing. I checked alsa-mixer and while I could adjust audio nothing improved the issue. I used pavucontrol to checked the audio-bars were properly moving in response to music being played, and they were, but no sound came from the speakers.
I did some searching, and tried to boot from the LTS kernel 6.18, the default LTS option for me with no success for any audio functionality. I tried booting from the live USB I installed my system through back in 2025 and the audio functioned correctly. This confirmed it wasn’t the hardware malfunctioning but something with the software that couldn’t be resolved with the kernel.
Search results for similar issues suggested redownloading the drivers and making sure the firmware and audio tools were up to date and functioning properly.
❯ sudo pacman -S pipewire pipewire-pulse wireplumber
❯ sudo pacman -S sof-firmware alsa-ucm-conf
❯ wpctl set-profile 43 analog-stereo
❯ hdajackretask
I clicked the override to assign the internal audio speaker to the internal audio speaker
❯ kate /usr/share/wireplumber/wireplumber.conf
inside wireplumber.conf, I altered the default (very low) value to 0.8, but audio still wasn’t working
sudo mv ~/.config/pulse ~/.config/pulse.old
mv ~/.config/wireplumber ~/.config/wireplumber.old
at this point I was out of ideas, out of relevant search results, and I wasn’t having any luck with reponses or even post views on the forum here, so sleep deprived and desperate I turned to using an AI for help:
❯ kate /etc/modprobe.d/p52-audio.conf
inside p52-audio.conf
options snd-intel-dspcfg dsp_driver=1
❯ rm -rf ~/.config/pulse ~/.config/wireplumber ~/.local/state/wireplumber
kate /etc/modprobe.d/p52-audio-fix.conf
inside p52-audio-fix.conf
options snd-intel-dspcfg dsp_driver=1
❯ kate /etc/modprobe.d/blacklist-audio.conf
Inside blacklist-audio.conf
blacklist snd_soc_avs
blacklist snd_sof
blacklist snd_sof_pci_intel_cnl
blacklist snd_sof_intel_hda_common
❯ systemctl --user stop pipewire pipewire-pulse wireplumber
rm -rf ~/.local/state/wireplumber/*
systemctl --user start pipewire pipewire-pulse wireplumber
❯ kate ~/.config/wireplumber/wireplumber.conf.d/60-disable-suspension.conf
inside 60-disable-suspension.conf:
monitor.alsa.rules = [
{
matches = [
{
node.name = "~alsa_output.*"
}
]
actions = {
update-props = {
session.suspend-timeout-seconds = 0
}
}
}
]
❯ systemctl --user restart pipewire pipewire-pulse wireplumber
❯ speaker-test -c 2 -t wav
in another terminal while the speaker test is running
❯ pactl list short sinks
Confirming that it’s running and not suspended while the speaker test is in effect, even if no audio can be heard.
❯ pactl set-sink-mute @DEFAULT_SINK@ 0
❯ pactl set-sink-volume @DEFAULT_SINK@ 100%
❯ pactl suspend-sink @DEFAULT_SINK@ 0
kate /etc/modprobe.d/alsa-base.conf
Inside alsa-base.conf
options snd-hda-intel model=headset-mode,dell-headset-multi
❯ amixer -c 0 scontrols
❯ amixer -c 0 sset Master 50%
❯ systemctl --user restart wireplumber
❯ kate ~/.config/wireplumber/wireplumber.conf.d/80-hw-volume.conf
Inside 80-hw-volume.conf
monitor.alsa.rules = [
{
matches = [
{
node.name = "~alsa_output.*"
}
]
actions = {
update-props = {
api.alsa.soft-mixer = false
api.alsa.ignore-dB = false
}
}
}
]
❯ kate ~/.config/wireplumber/wireplumber.conf.d/99-sync-fix.conf
Inside 99-sync-fix.conf:
monitor.alsa.rules = [
{
matches = [
{
node.name = "~alsa_output.*"
}
]
actions = {
update-props = {
api.alsa.ignore-dB = true
api.alsa.soft-mixer = false
}
}
}
]
systemctl --user restart wireplumber
sudo alsactl init
sudo alsactl store
At present, audio now properly assigns to the headphones when they’re plugged in, but after unplugging them I have to use “sudo alsactl init” again in order to reassign the internal speakers as the appropriate output source.
I’m aware some of these configs are duplicates, or even contradictory, but I don’t know enough on my own to deal with drivers or firmware to truly know what I’m doing or fix things properly.
in your terminal and this goes back even further. Handy as well if you want to check quickly.