Open lopsided98 opened 5 years ago
Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:
I'm currently grappling with this.
According to the manpage for udevadm
, possible "actions"/"types of event" are: add
remove
change
move
online
offline
bind
unbind
The udev rule installed by alsa-utils
is written to trigger on add
udevadm test
does not run the things specified in the rules, it only shows you what would run
By default, it tests actions with add
When I run sudo udevadm test /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/controlC0
, I get a similar output to what @lopsided98 pasted above, with a line indicating that alsactl restore
would run
udevadm trigger
does run the things specified in the rules
By default, it triggers actions with change
(not add
)
When I run sudo udevadm trigger
(not necessary to specify a particular thing, it just triggers everything), checking alsamixer
reflects that alsactl restore
has not run
When I run sudo udevadm trigger --action add
, checking alsamixer
reflects that alsactl restore
has run (ie, it worked, and the volume is restored to the previously saved state)
I did some very crude printf-debugging and found that my system is executing the first RUN+="..."
command in etc/udev/rule.d/90-alsa-restore.rules
sometime during system boot, so my previous comment may be a bit of a red herring.
How about: does something else need to be in place before alsactl restore
will work?
I just tested a machine running about a month old version of nixpkgs master and I can't reproduce this issue anymore. @gadtfly What nixpkgs version are you testing?
Thanks for checking.
To be completely honest, I'm not sure how to determine that or what precisely that means.
I installed this system from the 21.05 Graphical ISO some time around June 30th, I haven't explicitly done anything to do with channels, and I've run nixos-rebuild switch
a bunch times while connected to the internet. My nixpkgs version is in whatever state that would leave me in.
Here's where I'm at with this issue on my system:
90-alsa-restore.rules
90-alsa-restore.rules
run successfully runs alsactl restore
alsactl restore
run successfully restores the previously-saved ALSA volumealsactl restore
, or manual alsamixer
changes, or whatever)Here's the workaround that I'm trying:
systemd.user.services.alsa-restore-fix = {
after = [ "pulseaudio.service" ];
wantedBy = [ "pulseaudio.service" ];
script = "${pkgs.alsaUtils}/bin/amixer -c1 sset 'Speaker' 39";
};
I am not particularly familiar with writing systemd units so I have no idea if this is the "right" way to do this, but it seems to work.
I couldn't (sufficiently easily) figure out how to get a system-wide service to trigger on PulseAudio start (which happens per-user), so this is a user service.
I couldn't (sufficiently easily) figure out how to get alsactl restore
(which requires root permissions) to work in a user service, so I'm just setting the volume directly.
39
is 100% on this thing (the default it kept resetting to was 10
, which is 26%). The intention was always to manage the volume with PulseAudio. This seems to work so far.
Yeah, I'm pretty sure that is a different issue than mine, unless perhaps PulseAudio was implicitly enabled somewhere in my config. My machines that had this issue were headless, and did not intentionally enable PulseAudio.
I would guess that PulseAudio is trying to manage the volume itself, and there might be some way of persistently adjusting it from within the PulseAudio settings.
I'm starting to suspect that the root problem for me is that PulseAudio is not hooking itself in to my audio card's volume in the way it may be supposed to (I don't know, I'm not particularly famliar with PulseAudio either).
You're right that does seem to be a different issue.
Thank you for your help!
I marked this as stale due to inactivity. → More info
Any update on this? I'm having problems with alsa settings not being restored on startup.
Having this problem too
I am also having this problem. I found a workaround, but my machine is a little unusual so YMMV. You'll likely want to leave out line 138, at any rate, as that's specific to my particular setup.
The workaround, minus line 138, for your convenience:
services.udev.extraRules = ''
ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST="${pkgs.alsa-utils}", TEST="/var/lib/alsa/asound.state, GOTO="alsa_restore_go", GOTO="alsa_restore_end"
LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf",RUN+="${pkgs.alsa-utils}/bin/alsactl restore $attr{device/number}"
TEST=="/etc/alsa/state-daemon.conf",RUN+="${pkgs.alsa-utils}/bin/alsactl nrestore $attr{device/number}"
LABEL="alsa_restore_end"
'';
Other workaround if PulseAudio is installed:
Edit the file /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common
(on Debian)
Add or modify those element examples to not be altered by PulseAudio:
[Element Master]
switch = ignore
volume = ignore
[Element PCM]
switch = ignore
volume = ignore
[Element Front]
switch = ignore
volume = ignore
There is an equivalent for PipeWire.
Issue description
The udev rule that is supposed to restore ALSA state from
/var/lib/alsa/asound.state
does not seem to be working.alsa-store.service
correctly saves the ALSA state toasound.state
, but it is not restored on boot. Runningudevadm test /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/controlC0
gives this output:Manually running
/nix/store/nc2970g9gzhfiz2v6z10i7jbmbib7qy1-alsa-utils-1.1.7/sbin/alsactl restore 0
correctly restores the state.Steps to reproduce
Technical details
"x86_64-linux"
Linux 4.19.12, NixOS, 19.03pre164475.9ad20275d44-localpkgs (Koi)
yes
yes
nix-env (Nix) 2.1.3
""
"machines.HP-Z420.channel"
/nix/var/nix/profiles/per-user/root/channels/machines.HP-Z420.channel/nixpkgs