Description of problem: gnome-volume-control doesn't remember setings for PCM channel on reboot I set volume to 80% to both master and PCM channel, on reboot I expect them to be as I set them - but PCM channel repeatedly gets down to 50% Version-Release number of selected component (if applicable): How reproducible: every time Steps to Reproduce: 1. set volume of PCM and master channel to 80% 2. reboot the system 3. Actual results: PCM channel repeatedly gets down to 50% instead of staying at desired value before reboot. Expected results: PCM and master channels staying at chosen volume level. Additional info:
This is supposed to be done by the alsactl call in the halt initscript. As I don't think the initscript itself is the problem, I'd gather it's with alsactl.
Can you please attach /root/scsconfig.log? (it can be generated by system-config-soundcard). What sound device(s) is affected with this issue?
Mr. Stansky, I guess that all devices are affected by this issue. Why have not more people complained is that they have found a workaround. Instead of complaining, they saved the sound settings to their liking by becoming superuser $ su - password and typing # alsactl store and adding the line /usr/sbin/alsactl restore to the file /etc/rc.local file. This is the workaround that fixes this issue. With respect to the initscripts, where is it that the /usr/sbin/alsactl restore gets called? Thanks, Antonio
Created attachment 158792 [details] here is my /root/scsconfig.log here is my /root/scsconfig.log
This should be posted as a bug no matter if the workaround exists or not.
Created attachment 158800 [details] My SCSConfig.log file I too see this error, so attaching my log file too.
Created attachment 158808 [details] scsconfig.log of my system I have also noticed that the defaulted settings for each user is different. My main user (uid 500) has the default PCM set at 51%. For the "guest" (UID 501) user the setting is at 74%. Also, here's my system profile http://smolt.fedoraproject.org/show?UUID=1d344b4d-6329-4ae5-aa26-0b9e72a12d77
do you need some more feedback for this bug from me?
no, thanks for the report.
IMHO, there is nothing wrong with alsactl or salsa. Both do the job perfectly well. This bug should have been filed against the 'initscripts' package. /etc/init.d/halt calls /sbin/salsa to save the current configuration. But it is not called at startup by any script in /etc/init.d/ or /etc/rc.d/init.d/ to reload the configuration during boot. Also, why have a new thing called salsa that does it differently when 'alsactl store' did the job perfectly well to begin with. Jurgen mentioned in the users list that FC6 called alsactl, which means this new utility was added in FC7.
Daer all, Vivek is correct in what he has stated. The halt procedure calls salsa to save the settings, but there is no corresponding init script that calls salsa -l to load it at startup. In halt procedure there is # Save mixer settings, here for lack of a better place. grep -q "\(alsa\)" /proc/devices if [ $? = 0 -a -x /sbin/salsa ]; then action $"Saving mixer settings" /sbin/salsa -s fi When starting up there is something called Network Audio deamon or soemthing like that /etc/rc.d/init.d/nasd. Is it the one that should have the command /sbin/salsa -l [root@localhost ~]# cat /etc/rc.d/init.d/nasd #!/bin/bash # # nasd Starts nasd. # # # chkconfig: 345 88 88 # description: Network transparent audio server #Servicename SERVICE=nasd ...., Is this the file that should have "/sbin/salsa -l" or not? Where can we put the following # Load mixer settings, where for the lack of a place in initscripts? grep -q "\(alsa\)" /proc/devices if [ $? = 0 -a -x /sbin/salsa ]; then action $"Loading mixer settings" /sbin/salsa -l fi in here --> /etc/rc.d/init.d/nasd or where? Where should it be?
Air Collision or something like that happened. Sorry for posting double. Will ask on fedora-list/fedora-test-list which init script should be loading sound settings. Thanks, Antonio
Can we close this bug and file a new bud against the initscripts package? Martin, this bug is assigned to you. Your call.
Moved to initscripts. Thanks for your time and effort, guys.
The volume settings should be automatically restored by udev when the module is loaded; it is not an initscripts issue.
$ rpm -qf /etc/udev/rules.d/90-alsa.rules alsa-utils... $ cat /etc/udev/rules.d/90-alsa.rules SUBSYSTEM=="sound", KERNEL=="controlC*" RUN+="/sbin/salsa" SUBSYSTEM=="sound", KERNEL=="pcm*" RUN+="/sbin/salsa"
The volume settings should be automatically restored by udev when the module is loaded; it is not an initscripts issue. They SHOULD, but they are not. Is there any possibility that making a line similar to fc6's /etc/modprobe.conf which calls /sbin/alsactl -store, true and instead place /sbin/salsa -l could do the job? If it is not an initscripts issue, then how come putting in the line /sbin/salsa -l restores sound. Where is this line?/or where is it supposed to be in the initscripts?
On Fedora 6, the /etc/modprobe.conf on one of my machines looks like alias eth0 3c59x alias snd-card-0 snd-ali5451 options snd-card-0 index=0 options snd-ali5451 index=0 remove snd-ali5451 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-ali5451 install slamr modprobe --ignore-install ungrab-winmodem ; modprobe --ignore-install slamr; test -e /dev/slamr0 || (/bin/mknod -m 660 /dev/slamr0 c 242 0 2>/dev/null && chgrp uucp /dev/slamr0) The relevant part being: remove snd-ali5451 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-ali5451 all in one line, [olivares@localhost ~]$ /sbin/alsactl --help Usage: alsactl <options> command Available options: -h,--help this help -f,--file # configuration file (default /etc/asound.state or /etc/asound.names) -F,--force try to restore the matching controls as much as possible -d,--debug debug mode -v,--version print version of this program Available commands: store <card #> save current driver setup for one or each soundcards to configuration file restore<card #> load current driver setup for one or each soundcards from configuration file Changing this to Fedora 7, the /usr/sbin/alsactl equivalent is /usr/sbin/salsa with -r and -s r for restore and s for save. Will try that out and report back.
puttine in a line into /etc/modprobe.conf like FC6 does not help, Machines are different, using to compare only and make equivalent snd-ali5451 sound device in FC6 remove snd-ali5451 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-ali5451 snd-intel8x0 sound device in Fedora 7 remove snd-intel8x0 { /usr/sbin/salsa -s > /dev/null 2>! || : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0 does not work. Is there something else that we can try? Thanks, Antonio
Please try to copy these lines to /etc/udev/rules.d/90-alsa.rules SUBSYSTEM=="sound", KERNEL=="controlC*" RUN+="/sbin/salsa -l" SUBSYSTEM=="sound", KERNEL=="pcm*" RUN+="/sbin/salsa -l"
Done and that partially fixes the problem. The Master Volume setting is restored but PCM is *not*. I also tried replacing salsa with alsactl (with appropriate parameters) in /etc/init.d/halt and /etc/udev/rules.d/90-alsa.rules. The result is the same. Master Volume is restored and PCM isn't. alsactl in /etc/rc.local does the job though.
I do this: /etc/init.d/nasd restart and my PCM volume goes every time back to 50% this is still a bug for me...
That implies a NAS bug. Is anyone seeing this who isn't using nas?
Work around: add to /etc/rc.d/rc.local alsactl restore This is no real solution, but since the Fedora ALSA doesn't include the alsa initscript for starting and stopping the drivers (which by the way also call alsactl store and restore) and handled by udev rules (apparently) in the case of Fedora, you can walk around this issue with the above work around.
*** Bug 249804 has been marked as a duplicate of this bug. ***
*** Bug 243635 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > That implies a NAS bug. Is anyone seeing this who isn't using nas? I'll add that most people don't want to use NAS, but it's dragged in from the KDE libs, and the maintainer refuses to split the daemon and its libs. See bug 241378.
I have latest updates on my rawhide system and I still see this bug. Can you please confirm how do you plan to fix it. Thank you.
What would it happen if Fedora enabled by default the ALSA "driver initialization" init script so it would alsactl store and alsactl restore upon shutdown and reboot (respectively)? That's the way "kosher" ALSA does its magic, but in Fedora ever since migrating to ALSA this has been left out (that I could see, anyway), but when building from source, ALSA installed the alsasound service which is called upon system boot and again upon system shut down (to store and restore volume values). Will this cascade down to the new audio system, pluseaudio?
Fedora has loaded alsa mixer settings on boot and saved them on shutdown for the entirety of its existence - a separate script is not needed.
Since Fedora migrated from OSS to ALSA in FC2 (due to the new sound backend in the kernel) it was able to do so without the need of the "official" (upstream) service script, however, and without knowing what's the root cause of this issue which seems to linger in F8-test, seems the only way to walk around this is by means of either re-enabling the service script or hand the responsibility down to udev or some such.
In part, I'm somewhat confused because I'm *not* seeing this on any of my boxes. That being said, it's *already* loaded via udev; that's been what's loaded the settings on boot for multiple releases.
Why don't you just add alsa restore to some existing script until you find a more in depth solution... please don't let this bug linger forever...
Work around for me is to run alsa restore from /etc/rc.d/rc.local, still running alsa sotre in any of the shutdown scripts would be nice.
As stated before in comment #31, there *is* a call to store the mixer settings on shutdown, and has been there since the Red Hat Linux days.
If that was the case (and no it wasn't in the RHL days, not that I can remember, though, those were still the Open Sound System days), how come they are not restored when only issuing alsa restore after boot up, if you made changes to your mixer settings (either in alsamixer or gnome-mixer)?
(In reply to comment #37) > If that was the case (and no it wasn't in the RHL days, not that I can remember, > though, those were still the Open Sound System days) Trust me, it was the case (the commands have changed some over the years, but the code is there): rc.d/init.dhalt: revision 1.18 date: 1999/09/17 15:30:46; author: notting; state: Exp; lines: +6 -0 load/save mixer settings here. which is RHL 6.1. , how come they are not > restored when only issuing alsa restore after boot up, if you made changes to > your mixer settings (either in alsamixer or gnome-mixer)? I've just tried again on a fresh rawhide install, and it works fine for me - I login, change the volume with alsamixer/gnome-volume-control. I then reboot, and the settings are restored properly. So, let's go back to the basics. Please attach: - /etc/alsa/asound.state - the output of 'amixer' when the volume is *not* restored correctly
Created attachment 199901 [details] asound.state asound.state
Created attachment 199911 [details] amixer amixer
I installed all the latest updated to my Fedora Devel (Rawhide) system and I still have this issue. 1. I rebooted the system after updates (new kernel). 2. I opened gnome's Volume Control (Alsa mixer) and set my PCM volume to ~95% 3. I rebooted my system 4. I opened Volume Control (Alsa mixer) and I saw that PCM volume was back on 50% and not 95% as I left it! This is still an open bug. I already posted the attachments you requested. Please fix this issue.
On a clean install I watched the shutdown messages carefully and there was a failed one (you guessed it, saving mixer settings), however this was on a ATI IXP motherboard with ATI HD audio (which I believe use a different driver than the one system-config-soundcard picked, I don't think the right driver for this chip is the Intel HDA), when we get around to installing updates we'll see... We are having trouble with networking due to known bugs in the RealTek 8139too driver, and the fact that it is a laptop with an Atheros Wifi card which doesn't seem to like Madwifi :-/
OK, so, examining those attachments: - /etc/asound.state is correct (main volume 87/89, pcm playback ~95%) Conclusion #1: settings were saved correctly. - On reboot, your main volume is restored to 87/89, and your capture volume is restored to 53%. Conclusion #2: settings *are* being restored (alsa starts up muted by default) - However, your PCM volume is 52%. This means one of two things is happening: 1) alsa isn't reading the value right for PCM when it restores it This would be unlikely, as if so, it would almost certainly be setting it to 0. 2) some other service/program is resetting PCM volume to zero. That's the assumption I'm going with for now. So: - what services do you have running? - what programs do you have running in your default gnome session? - if you log in on the console (instead of GNOME), is the volume also wrong for PCM?
Oops, replace 'resetting PCM volume to zero' with 'PCM volume to 50%'.
> - if you log in on the console (instead of GNOME), is the volume also > wrong for PCM? In my case, without my alsa restore hack in /etc/rc.d/rc.local, it does reset to 52% even in an init 3 (in GRUB append a 3 at the end of the kernel arguments to boot straight into init 3)
Created attachment 200191 [details] asound.state
I have the same problem with a M-Audio Revolution 7.1
I did an new update to my rawhide box and after reboot I got no sound at all! I ran system-config-soundcard and after another reboot I tested and saw that this bug is still present. What more feedback can I give you?
(In reply to comment #48) > I did an new update to my rawhide box and after reboot I got no sound at all! > I ran system-config-soundcard and after another reboot I tested and saw that > this bug is still present. > > What more feedback can I give you? This is completely unrelated to this bug. Make sure ConsoleKit and hal are running (your user doesn't have access permissions to the /dev/snd/* devices, ConsoleKit is supposed to give the user access to those devices when logged in).
# /etc/init.d/ConsoleKit status console-kit-daemon (pid 1945) is running... # /etc/init.d/haldaemon status hald (pid 2120) is running... $ ls -al /dev/snd/* crw-rw----+ 1 root root 116, 8 2007-10-02 19:18 /dev/snd/controlC0 crw-rw----+ 1 root root 116, 7 2007-10-02 19:18 /dev/snd/pcmC0D0c crw-rw----+ 1 root root 116, 6 2007-10-02 19:18 /dev/snd/pcmC0D0p crw-rw----+ 1 root root 116, 5 2007-10-02 19:18 /dev/snd/pcmC0D6c crw-rw----+ 1 root root 116, 4 2007-10-02 19:18 /dev/snd/pcmC0D6p crw-rw----+ 1 root root 116, 3 2007-10-02 19:18 /dev/snd/seq crw-rw----+ 1 root root 116, 2 2007-10-02 19:18 /dev/snd/timer what else?
Gian, Chris, could you attach the output of: /sbin/chkconfig --list
Created attachment 219021 [details] Chkconfig --list out put Here goes the output
Gian - what happens if you turn off/uninstall nasd?
Actually, never mind. On the basis of comments #23/#24, assigning this where it should have been since day one.
To be honest, I don't even see why NAS is starting by default.
I know NAS got pulled as a dependency for something I installed, problem is that I don't remember what was it. I have already disabled it, and removed it from the chkconfig table, will remove my "workaround" in rc.local (alsactl restore) and reboot, see what happens.
(In reply to comment #55) > To be honest, I don't even see why NAS is starting by default. Because it's dragged by GStreamer or arts, which is why I filed bug 241378 some time ago. Maybe I should reopen it...
Notting is right; once I uninstalled nas the problem went away. Apparently I got it dragged in by installing qt4, though I could swear this was a problem from day one, and I didn't install qt4 until I'd been running the system for a few weeks. Odd.
According to my install.log, nas was installed during my clean install of F7. I didn't do much if any customization of packages so it must be part of one of the standard package groups.
I'm having a similar problem on two different machines running F7. One has an boring ATI IXP200M+AC97, while the other has an SBLive board. Both were upgraded from FC6. (technically only the old FC6 homedirs were kept) On bootup, it remembers all mixer settings except PCM, which is set to rougly 50% on startup. The curious thing is that when I run xine to play a random video file, the volume is reset to 50%. I set the volume to, say, 90%, quit xine, and restart it -- the volume is once again set to 50%. It would appear that something that xine loads is causing the PCM value to be reset. Xine has an option that allows it to remember the mixer setting and restore it on startup, but that is *not* enabled. (If I enable it, xine remembers and restores the PCM setting to something sane -- but without the option turned on, PCM gets reset to 50% each time) I can open a new bug against xine, but this problem seems to be related.
To follow up on my last note -- it appears that loading xine triggers a mixer settings load; the PCM value stored in /etc/alsa/asound.state is restored each time I fire up xine. Is this some sort of udev "reset volume on pcm dev open" wierdness?
Is it reasonable to expect that this bug gets fixed before Fedora 8 ships or not?
I can't reproduce it on my systems. I have test it with 3 systems all works ok. So I think the bug must be at another location.
Created attachment 246821 [details] patch for this issue No, it's a NAS bug. Perhaps you're not seeing it because your mixer doesn't have a PCM channel?
Have you try 1.9a to check if this need the patch to?
It has the same code, so I don't see why it wouldn't.
Ok I build an new package and send the path to the developers.
I have get an mail from the developer of nas, that patching is unnecessary, try to change MixerInit "yes" to MixerInit "no" at the config file /etc/nas/nasd.conf. Can you test it?
Works for me - can we get that changed in the default config? (For F8 updates too would be nice.)
Yes. I will modify it.
nas-1.9a-3.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
nas-1.9a-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.