Volume suddenly caps out at 10%

raxod502 · 2026-05-08 04:53:23

Hi, I use Arch Linux on the System 76 Oryx Pro 6, using a mostly unconfigured GNOME 50.1. Apropos of nothing I can tell (e.g., no pacman operations and no config file changes), today my sound output is behaving very strangely, and persists after reboot.

What I observe is that the audio output stops getting louder at around 10% of the way up the system volume meter, even as I move the slider up further. When I look in alsamixer, I can see the same thing quantitatively. PCM is smoothly increasing from 0 to 100 during the first 10% of the system volume meter, and that is the time during which actual audio output gets louder, then Master starts increasing from 0 to 100, which has no effect on actual output volume. The slider for headphone (or speaker) is totally missing, it shows unmuted but volume level cannot be adjusted. I correspondingly observe the same thresholding behavior whether I am using headphones or speaker on the laptop, but bluetooth headphones work fine.

Oh, and another thing that's really weird: it's definitely not an issue with what audio level the hardware can produce, because if I use pavucontrol to increase the gain on a specific output stream past 100%, it does get louder. I've found no other way to increase actual sound output past the 10% threshold.

My system uses PipeWire which I understand is nowadays the default for the version of GNOME packaged by Arch.

I suspect the issue might have something to do with the fact that headphone/speaker don't show a volume control in alsamixer, is there a way to find out why that is happening?

pw-dump: https://files.intuitiveexplanations.com … th9e7k.txt
pacman -Q: https://files.intuitiveexplanations.com … iNQ39i.txt
dmesg: https://files.intuitiveexplanations.com … mHrliE.txt

The only configuration file I've written is a WirePlumber one to disable the poor quality built-in mic, and disable HDMI audio output. But that hasn't changed in weeks.

monitor.alsa.rules = [
  {
    matches = [
      {
        node.name = "alsa_input.pci-0000_00_1f.3.analog-stereo"
      }
    ]
    actions = {
      update-props = {
        node.disabled = true
      }
    }
  }
  {
    matches = [
      {
        device.name = "alsa_card.pci-0000_01_00.1"
      }
    ]
    actions = {
      update-props = {
        device.disabled = true
      }
    }
  }
]

Let me know if I missed an important configuration file.

raxod502 · 2026-05-08 05:28:50

Somehow, despite my having already tried rebooting several times to no avail, I flashed a Pop!_OS 24.04 live USB to see if the problem happened in a live environment supported by the hardware vendor. It didn't, and then when I booted back into Arch, the problem is no longer occurring. I didn't change any configuration. What the heck?

Also, I have noted that the alsamixer visual behavior is exactly the same as I observed in my post above, but real audio output works fine now. So none of that behavior was the cause of the issue, apparently. It just looks different between the two Arch laptops I tested on, I guess because of ALSA detecting different behavior between the two sound cards. The other laptop I checked was a Framework 13.

I still don't know what happened here and would love to learn more so I don't feel like the problem appeared and then later disappeared by magic.

raxod502 · 2026-05-12 00:00:52

Well, it was okay for a while as previously described, but now it's gone back to the broken behavior from before. I installed Arch Linux fresh on another partition, basically just the base packages plus the default GNOME group, and the issue is not happening on that, on the same hardware. But then I change back to my main installation and it's broken again. So, some configuration? I'm at a loss as to what.

I noticed that on the fresh installation I was using pipewire-jack rather than the jack2 of my broken installation, so I changed over on my broken installation and rebooted. This did not produce any change however.

I am very confused why this is happening.

UPDATE: Since I was seeing things work on a fresh Arch partition, I decided to bisect between user and system configuration, by creating a new user account. Same broken behavior on the new user account - so it must be system configuration. I reviewed https://wiki.archlinux.org/title/Pacman/Tips_and_tricks to find that I could use `sudo pacreport --unowned-files`. Since, after all, what is a Linux system but the package versions plus any files not tracked by the package manager, right? The one file in that list that stood out to me as possibly related was /var/lib/alsa/asound.state. I booted to a recovery partition and removed/renamed that file. When I booted back into my normal system, the volume slider was working exactly like it should. I guess we will see if that trend continues. For posterity, my old asound.state file had these contents, maybe they explain to someone why the volume was maxing out at 10%: https://files.intuitiveexplanations.com … zdxl0p.txt

If the issue doesn't recur for a while, I'll consider it solved and close out this thread.

Last edited by raxod502 (2026-05-12 00:40:23)

seth · 2026-05-12 10:12:16

https://wiki.archlinux.org/title/Advanc … nd_systemd
If the situation returns

amixer -Dhw:0
amixer -Dhw:1

might explain the symptom - question would be what jinxed it during the last re/boot. You could at least check the status of alsa-restore.service to see whether anything went wrong during the boot.
The storage might at best be preserved in the journal of the previous boot.

Arch Linux

#1 2026-05-08 04:53:23

Volume suddenly caps out at 10%

#2 2026-05-08 05:28:50

Re: Volume suddenly caps out at 10%

#3 2026-05-12 00:00:52

Re: Volume suddenly caps out at 10%

#4 2026-05-12 10:12:16

Re: Volume suddenly caps out at 10%

Board footer