You are not logged in.
I found that my options here are either to leave /etc/alsa with no state-daemon.conf to use alsa-store.service and alsa-restore.service or to touch that file to cause alsa-state.service to take over. What if I want to load the same volume state every time the computer starts (in my case, load in with the speakers muted)? Would it be safe to remove alsa-store.service from /usr/lib/systemd/system and keep it under my root's home directory, or should I just write a service to mute on boot, instead?
Last edited by Thisguy_ (2014-09-04 17:50:17)
Offline
It will keep reappearing after a system/alsa-utils update/upgrade. You can write your own scripts, or simply load the configuration you want as a user.
alsactl store -f ~/.alsa.state
# and in ~/.xinitrc or similar
alsactl restore -f ~/.alsa.stateAnd leave alsa-restore.service disabled.
Edit: Maybe I missed here something, you could simply run:
# alsactl storewith you preferred settings, it should be loaded at each boot by alsa-restore.service if the /etc/alsa/state-daemon.conf file does not exist.
Last edited by emeres (2014-09-04 17:31:21)
Offline
I tried running alsactl store at boot, but alsa-store.service does that on shutdown as well - therein lies the problem. I suppose a better way to do this would be to switch to using alsa-state.service and then add alsactl restore to my .xinitrc. I'll give that a try now.
EDIT: Didn't work. Running alsactl restore manually complains of a state lock on a file and does not mute the speakers.
Let me be more specific about these services - they're statically loaded. They execute themselves as the result of a file exist test on /etc/alsa/state-daemon.conf, and either alsa-state or alsa-store and alsa-restore take over - alsa-state if it exists and alsa-(re)store if it doesn't.
EDIT: That's what I get for not reading. Switched back to store and restore and changing alsactl restore to alsactl restore -f ~/.alsa.state after having generated that file. Here goes nothing.
EDIT: Like a charm. Thanks!
Last edited by Thisguy_ (2014-09-04 17:50:03)
Offline
Using this for alsa-restore service this should work, but untested, alsa-store needs to be disabled.
$ cat /etc/systemd/system/alsa-restore.service
#
# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#
[Unit]
Description=Restore Sound Card State
ConditionPathExists=!/etc/alsa/state-daemon.conf
DefaultDependencies=no
After=sound.target
Before=shutdown.target
Conflicts=alsa-state.service shutdown.target
# Just to make sure alsa-state also conflicts
[Service]
Type=oneshot
ExecStart=-/usr/bin/alsactl restore
StandardOutput=syslogYou are welcome.
Offline
Actually, the previous solution that did not require modifying the default alsa-related service behavior was the solution that I prefer and it ended up working. That's what I was thanking you for.
And keep in mind that to "disable" alsa-store, I would have to remove it from its current directory, since it's statically enabled.
Last edited by Thisguy_ (2014-09-05 14:14:43)
Offline
This one takes precedence over the one from alsa-utils package and stays in place, so it has to be done only once and is global. Renaming '# mv alsa-store.service{,.disabled}' should be sufficient. I usually refer to this by disabling a file in that manner, but yes, here it might have been confusing, because of systemd vocabulary, my bad. And you would have to repeat it, so masking it, creating a symlink to /dev/null inside /etc/systemd/system, would have been the correct approach.
Offline