Description of problem: The shutdown scripts invoke alsactl store to save settings, but as far as I can tell, alsactl restore is not called anywhere on boot to restore them. I asked on the fedora list if this was a bug and haven't gotten a response, so decided to file a bug. Version-Release number of selected component (if applicable): initscripts-9.21-2.fc15
Do you have alsa-utils installed? [root@cedar ~]# rpm -q alsa-utils alsa-utils-1.0.23-3.fc14.x86_64 [root@cedar ~]# rpm -ql alsa-utils | grep udev /etc/udev/rules.d/90-alsa.rules [root@cedar ~]# cat /etc/udev/rules.d/90-alsa.rules ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", \ RUN+="/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore /dev/$name" ACTION=="remove", SUBSYSTEM=="sound", KERNEL=="controlC*", \ RUN+="/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf store /dev/$name"
I have alsa-utils-1.0.23-3.fc13.x86_64 installed in F13, and the identical file, but somehow, restoring settings doesn't work automatically. To get the settings restored, I have to manually run "alsactl restore" as root. However, saving settings at shutdown does seem to work (the modification time on /etc/asound.state is updated at shutdown, once the SELinux context has been fixed).
(In reply to comment #2) > I have alsa-utils-1.0.23-3.fc13.x86_64 installed in F13, and the identical > file, but somehow, restoring settings doesn't work automatically. To get the > settings restored, I have to manually run "alsactl restore" as root. However, > saving settings at shutdown does seem to work (the modification time on > /etc/asound.state is updated at shutdown, once the SELinux context has been > fixed). OK. In a test with F13 (with gnome and pulseaudio), alsamixer settings are restored automatically. My procedure is to use alsamixer to change the master volume, quit, restart, and check the master volume again with alsamixer. alsa-lib-1.0.23-1.fc13.i686 alsa-lib-1.0.23-1.fc13.x86_64 alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64 alsa-utils-1.0.23-3.fc13.x86_64 initscripts-9.12.1-1.fc13.x86_64 udev-153-4.fc13.x86_64 (This is an x86_64, the i686 libraries are to accommodate adobe flash.)
The setting that fails to be restored for me is my headset volume (see bug 588098). I'll check if the master volume can be changed and restored next time I get a chance to reboot. In any case, I don't understand why if alsa-utils is supposed to handle this, initscripts tries to do so as well, and why it only tries to do it for shutdown and not for startup.
(In reply to comment #3) > ... My procedure is to use alsamixer to change the master > volume, quit, restart, and check the master volume again with alsamixer. Invoked as: $ alsamixer -c0 (That displays all the analog volume bars. Otherwise I get one bar and have to select the device with the F6 key. I believe that is related to pulseaudio ...) And I have been trying for months to figure out how sound settings work ... :-)
In a fresh install of F14 (gnome desktop, updated) in a VM, the Master volume is saved and restored, but the PCM volume is not. After setting the PCM volume to 100 and rebooting, it is reset to 81. $ qemu-kvm -m 512m -hda f14-fir.img -soundhw es1370 In the VM: # alsactl store # restorecon -v /etc/asound.state # work around Bug 637291 $ alsamixer -c0 # change Master and set PCM to 100 $ reboot $ alsamixer -c0 NB: AFAICT, the host actually controls the volume heard in headphones, and the VM volume settings are ignored, except when muted.
Regarding the reassignment of this bug: I filed it specifically because of the fact that initscripts invokes alsactl store, but not alsactl restore. I changed the Summary to make this clear. If necessary, I'll file a separate bug concerning possible alsa-utils issues.
The restore is done, via udev, on module load. Hence, the reassignment to where the restore is done. It is not a bug that initscripts doesn't do the restore. If you want, I could close it as that, but I figure reassigning it to the proper place makes more sense.
Ok, reassigning to alsa-utils and changing the Summary to only mention the restoring of mixer settings on startup.
Changing the Version from rawhide to 13 since at the moment I can only verify the alsa-utils issue on F13. alsa-utils-1.0.23-3.fc13
(In reply to comment #8) ... > If you want, I could close it as that, but I figure reassigning it to the > proper place makes more sense. Thanks, Bill. You have no idea how angry I get when you reds close my bug ...
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.