Restoring ALSA state upon reboot

[CaffeineAddict]

Problem:
ALSA levels set in alsamixer do not persist, upon reboot they're reset to driver defaults.

The service responsible to ALSA restore is alsa-restore:

sudo systemctl status alsa-restore
[sudo] password for <user>:
● alsa-restore.service - Save/Restore Sound Card State
     Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
     Active: active (exited) since Sat 2025-11-08 10:26:32 CET; 48min ago
 Invocation: db28511a7c5647509e9fbd050fba471d
       Docs: man:alsactl(1)
    Process: 1334 ExecStart=/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore (code=exited, status=0/SUCCESS)
   Main PID: 1334 (code=exited, status=0/SUCCESS)
   Mem peak: 1.8M
        CPU: 8ms

stu 08 10:26:32 <user> systemd[1]: Starting alsa-restore.service - Save/Restore Sound Card State...
stu 08 10:26:32 <user> systemd[1]: Finished alsa-restore.service - Save/Restore Sound Card State.

I adjust desired ALSA levels in alsamixer then I save the levels with:

sudo alsactl store

This command writes ALSA levels to the following file:

/var/lib/alsa/asound.state

However upon reboot the alsa-restore service does not restore the levels saved in that file.
To restore them I have to manually restore them in terminal with the following command every time after boot:

sudo alsactl restore

Then they're restored, however it's tedious to restore them manually after each reboot.

Workaround:
I've found a workaround for this by creating a login script that restores them upon login, the login script has the following code:

#!/bin/bash
/usr/sbin/alsactl --file ~/.config/asound.state restore

Ofc. for this login script to work I first have to store the levels to this file with:

/usr/sbin/alsactl --file ~/.config/asound.state store

This works but...
Problem is that alsa-restore service should do this automatically without hackery with login script, because that's its purpose.

Question:
How do I make alsa-restore service restore ALSA levels without login script?
Or what else am I missing or need to do?

Additional context for troubleshooting:
I use pipewire and wireplumber to manage audio.

Here are details about my audio:

inxi -Axx
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Micro-Star MSI
    driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a348
  Device-2: NVIDIA TU106 High Definition Audio vendor: InnoVISION
    driver: snd_hda_intel v: kernel pcie: speed: 2.5 GT/s lanes: 16
    bus-ID: 01:00.1 chip-ID: 10de:10f9
  API: ALSA v: k6.12.48+deb13-amd64 status: kernel-api
  Server-1: PipeWire v: 1.4.2 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active

I initially suspected wireplumber or pipewire overrides ALSA levels, however the login script workaround refutes this since I'm able to restore them despite wireplumber and pipewire being active.
I have no proof that this is the case so it's open for further troubleshooting.

There is however also another ALSA service:

sudo systemctl status alsa-state
○ alsa-state.service - Manage Sound Card State (restore and store)
     Loaded: loaded (/usr/lib/systemd/system/alsa-state.service; static)
     Active: inactive (dead)
  Condition: start condition unmet at Sat 2025-11-08 10:26:32 CET; 1h 6min ago
             └─ ConditionPathExists=/etc/alsa/state-daemon.conf was not met
       Docs: man:alsactl(1)

stu 08 10:26:32 <user> systemd[1]: alsa-state.service - Manage Sound Card State (restore and store) was skipped because of an unmet condition check (ConditionPathExists=/etc/alsa/state-daemon.conf).

Note the last line which says:

Condition: start condition unmet at Sat 2025-11-08 10:26:32 CET; 1h 6min ago
└─ ConditionPathExists=/etc/alsa/state-daemon.conf was not met

It says the service failed to start due to missing /etc/alsa/state-daemon.conf
I tried to sudo touch /etc/alsa/state-daemon.conf to satisfy this problem, however this results other service alsa-restore to complain about the opposite condition (that the file must NOT exist):

sudo systemctl status alsa-restore
○ alsa-restore.service - Save/Restore Sound Card State
     Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
     Active: inactive (dead) since Sat 2025-11-08 11:37:20 CET; 913ms ago
   Duration: 1h 10min 47.373s
 Invocation: db28511a7c5647509e9fbd050fba471d
  Condition: start condition unmet at Sat 2025-11-08 11:37:20 CET; 911ms ago
             └─ ConditionPathExists=!/etc/alsa/state-daemon.conf was not met
       Docs: man:alsactl(1)
    Process: 1334 ExecStart=/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore (code=exited, status=0/SUCCESS)
    Process: 7383 ExecStop=/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime store (code=exited, status=0/SUCCESS)
   Main PID: 1334 (code=exited, status=0/SUCCESS)
   Mem peak: 1.7M
        CPU: 27ms

Now this service says:

Condition: start condition unmet at Sat 2025-11-08 11:37:20 CET; 911ms ago
└─ ConditionPathExists=!/etc/alsa/state-daemon.conf was not met

It says the file must NOT exist.

Therefore if file exists alsa-restore fails, if it doesn't exist then alsa-state fails, so it's no-win situation regarding this file, and I have no clue what this file should contain and how to pupulate it and whether I should wory about it at all.
I'm not even sure which of the 2 services are responsible for restore on boot and what's the difference between them.

There are plenty of complaints online on forums and various sites, however no actual solution that works except login script.

System:
Debian Trixe

cat /etc/debian_version
13.1

edit:
About the 2 ALSA services according to search assist:

The alsa-restore service saves and restores the sound card state using the file /var/lib/alsa/asound.state, while the alsa-state service manages sound card state continuously in daemon mode, requiring a configuration file at /etc/alsa/state-daemon.conf. Both services are mutually exclusive, meaning you can only use one at a time based on your needs.

However none of the 2 restore ALSA levels, regardless of which one I use.

I can't store settings to /var/lib/alsa/asound.state because it requires root:

/sbin/alsactl store
/sbin/alsactl: state_lock:168: file /var/lib/alsa/asound.state lock error: Permission denied

But saving as root does not restore ALSA on boot, hence login script instead of alsa-restore service.

 

[f33dm3bits]

Additional context for troubleshooting:
I use pipewire and wireplumber to manage audio.

Here are details about my audio:

Just of of curiosity why do you need alsamixer to manage your audio volumes. If I remember correctly you use KDE Plasma and you can just use audio volume control from you DE. Why not do that?

can't store settings to /var/lib/alsa/asound.state because it requires root:
/sbin/alsactl store /sbin/alsactl: state_lock:168: file /var/lib/alsa/asound.state lock error: Permission denied

You can setup a systemd-unit-file in /etc/systemd/system/astate.service

[Unit]
Description=Set alsa state during boot

[Service]
Type=oneshot
ExecStart=/sbin/alsactl store

[Install]
WantedBy=multi-user.target

Then enable it during boot.

systemctl enable astate.service

 

[osprey]

Problem:
ALSA levels set in alsamixer do not persist, upon reboot they're reset to driver defaults.
....
Here are details about my audio:

inxi -Axx
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Micro-Star MSI
    driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a348
  Device-2: NVIDIA TU106 High Definition Audio vendor: InnoVISION
    driver: snd_hda_intel v: kernel pcie: speed: 2.5 GT/s lanes: 16
    bus-ID: 01:00.1 chip-ID: 10de:10f9
  API: ALSA v: k6.12.48+deb13-amd64 status: kernel-api
  Server-1: PipeWire v: 1.4.2 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active

There's a slight difference between your inxi output and that on this machine, though this machine is forky:

$ inxi -Axx
Audio:
  Device-1: Intel Raptor Lake High Definition Audio vendor: ASRock
    driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:7a50
  Device-2: NVIDIA GK208 HDMI/DP Audio vendor: Micro-Star MSI
    driver: snd_hda_intel v: kernel pcie: speed: 5 GT/s lanes: 8 bus-ID: 01:00.1
    chip-ID: 10de:0e0f
  API: ALSA v: k6.16.12+deb14+1-amd64 status: kernel-api
  Server-1: PipeWire v: 1.4.9 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin

The difference is that inxi cites pipewire-alsa, so I was wondering if it was installed on your machine. Maybe a red herring, but just a thought.

It might be useful to look at the amixer command if taking the scripting route since amixer can set levels.

 

[CaffeineAddict]

Just of of curiosity why do you need alsamixer to manage your audio volumes. If I remember correctly you use KDE Plasma and you can just use audio volume control from you DE. Why not do that?

First, there is a bug where not all audio profiles remember wireplumber audio levels due to a bug, only "Audio Pro" profile works well with wireplumber in KDE, so I've solved this with "Audio Pro" profile.

Solved in this thread:

Microphone re-enables and resets on its own

This is what I do to disable microphone: I also try to reduce gain to 0%: This is how it reverts to enabled state and 100% gain every time I reboot system: Why can’t this applet remember my preference and how to fix? is it a bug? Additional info, there is no microphone attached...

discuss.kde.org

why do you need alsamixer

Because master in alsamixer is set to very low level so I can't get maximum audio output, need to run alsamixer and up the master level manually.

You can setup a systemd-unit-file in /etc/systemd/system/astate.service

I've already solved this with login script, problem is both the script or a separate systemd service is redundant because alsa-resotore should handle this but it doesn't.

I'm trying to avoid extra code for something that's already there but doesn't work, I need a fix or explanation for alsa-restore service instead of a workaround.
The service is supposed to work without any workarounds.

The difference is that inxi cites pipewire-alsa, so I was wondering if it was installed on your machine. Maybe a red herring, but just a thought.

According to:

Debian -- Details of package pipewire-alsa in trixie

This package contains a plugin for ALSA applications to output via PipeWire

Doesn't sound promising but I'll install it and see if this works.

edit:

The difference is that inxi cites pipewire-alsa, so I was wondering if it was installed on your machine. Maybe a red herring, but just a thought.

Installed the package and it works, wireplumber master level is now synced to alsamixer master.
Adjusting one adjusts the other to same value.

But with this package alsamixer has only master level available to tune, other levels are absent.
I guess this solves it, thanks!

Still I'd like to know why alsa-restore didn't do the job?

edit2:
Actually no, it's not solved sorry.
Now the problem is that audio output is really low, it's not as loud as before even when maxed out to 100%, it plays like at 40%