Description of problem: When manually setting the master output volume level to below the highest level possible using kmix, the setting does not survive a system reboot. Version-Release number of selected component (if applicable): kmix-4.11.1-1.fc19.x86_64 How reproducible: Every system reboot. Steps to Reproduce: 1. Manually set volume for the master channel output to less than 100%, say 40%, using kmix. 2. Play some audio to check that the change has taken effect. 3. Reboot the machine 4. Check the volume level of the master channel once logged in to the same user account. The volume is now set to 100% and not the previously manually set volume. Actual results: The manually set volume level of the master output channel never survives a reboot. Expected results: The manually set level of the master output channel survives a reboot. Additional info: The manually set level of the master output channel survives a login\logout.
I believe alsa-utils's alsa-state service is supposed to handle that part these days (I believe). What does this command display for you? (and compare to my results) $ 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: active (running) since Tue 2014-01-14 11:32:49 CST; 2 weeks 1 days ago Main PID: 403 (alsactl) CGroup: name=systemd:/system/alsa-state.service └─403 /usr/sbin/alsactl -s -n 19 -c -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main rdaemon
Also note that the pulseaudio can modify the volume after reboot, so it would be good to check the situation without pulseaudio.
I can replicate Rex's output from: systemctl status alsa-state. My experience with losing the user's volume level setting occurs after every logout - login cycle, as well as at a system reboot, agrees with your experience. In our experience, the volume is reset to the '100%' level (default), ignoring the far right slider setting (presumably 153%). FWIW I'm using gdm 3.10.0.1-1.fc20.x86_64, kernel 3.12.10-300.fc20.x86_64
This remains the case with the kernel now updated to 3-13-6-200 Pulseaudio can continue to modify the volume after reboot, or at any other point, for that matter. That's not the problem. The problem is that it cannot RETAIN the settings after a logout and or a reboot. Taking out pulseaudio will also take out 76 other packages so I am not intending to go there. GJW
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
(In reply to Rex Dieter from comment #1) > I believe alsa-utils's alsa-state service is supposed to handle that part > these days (I believe). > > What does this command display for you? (and compare to my results) > > $ 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: active (running) since Tue 2014-01-14 11:32:49 CST; 2 weeks 1 > days ago > Main PID: 403 (alsactl) > CGroup: name=systemd:/system/alsa-state.service > └─403 /usr/sbin/alsactl -s -n 19 -c -E > ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main > rdaemon Hi Rex, sorry for not replying sooner I have been rather busy. This bug in Fedora 19 has many layers. The alsa-state service and also the alternative alsa-store/alsa-restore method do not work correctly. The settings are not stored. The kmix setting to restore volumes at login appears to override alsa settings also (by setting volumes to 100% or 0db not sure if this is intended.) I peeled back pulseaudio (I have no use for it) and it revealed a huge mess in the wake of how pulseaudio is being deployed in Fedora. From device detection to default mixer devices, the pulseaudio integration just makes too many intrusive changes to a default alsa install. Without actually doing so, from what I have seen, removing pulseaudio completely appears as though it would render a Fedora system completely without working sound I/O even if alsa is still there. I had to make some very intrusive modifications here just to get an onboard sound card to do I/O as expected without pulseaudio and I don't think I should have had to. (In reply to Jaroslav Kysela from comment #2) > Also note that the pulseaudio can modify the volume after reboot, so it > would be good to check the situation without pulseaudio. This report is filled against alsa-utils and not pulseaudio. pulseaudio has been purged here, although I understand the assumption. (In reply to George Walsh from comment #4) > This remains the case with the kernel now updated to 3-13-6-200 > > Pulseaudio can continue to modify the volume after reboot, or at any other > point, for that matter. > > That's not the problem. The problem is that it cannot RETAIN the settings > after a logout and or a reboot. > > Taking out pulseaudio will also take out 76 other packages so I am not > intending to go there. > > GJW Yeah it's not easy and there is zero reason for it to have so many hard deps on packages which make use of it but do not _depend_ upon it. The entire audio stack needs looking at because pulseaudio integration has made changes to the way alsa works by default and has created hard deps in rpms, deps which do not exist. I will attach my systemd service which works for me for restoring and loading the volumes and also the modifications I had to make to alsa just to get the default card to work. BTW /etc/alsa/asound.state needs to be created before hand and to have the correct selinux context.
Created attachment 990061 [details] alsa-save systemd service Saves alsa volumes before shutdown.
Created attachment 990062 [details] alsa-load systemd service Loads saved alsa configuration at boot.
Created attachment 990063 [details] /etc/alsa/alsactl.conf This file /etc/alsa/alsactl.conf has optional settings which could be put into the alsa-save or alsa-load services but they actually belong in alsactl.conf so that's where I put them.
Created attachment 990065 [details] /usr/share/alsa/alsa.conf.d/20-default.conf I had to manually create the file /usr/share/alsa/alsa.conf.d/20-default.conf and delete the pulse audio configuration file in the same directory which was set to allow pulse audio to by default control alsa system wide just to get sound from alsa.
> The kmix setting to restore volumes at login appears to override alsa settings fyi, possible, but it's a no-op is pulseaudio is used.
Well, here I am one year later on this bug. I've somehow now convinced 'the ghost in the machine' to maintain a user's sound levels through a logout/login cycle, or so it would appear, anyway. What I did was: 1) Install pavucontrol 2) Disable flat-volumes in /etc/pulse/daemon.conf by changing the line reading ; flat-volumes = yes with a line reading flat-volumes = no REBOOT for good measure. Now, for each individual user: 3) Log in to that user's account 4) Invoke pavucontrol Under the Configuration tab, for 'Built-in Audio, set profile to 'Off' and for GF108 High Definition Audio Controller, set profile to 'Digital Stereo (HDMI 4) Output. Under the Output Devices tab, for the HDMI port, move both front output sliders to the farthest right (153% 11.00db) 5) Invoke Settings -> Sound and under the Output tab select Device HDMI/DisplayPort 4 - GF108 H.D. Audio Controller and slide volume level to the far right if it is not already there. 6) Verify the setting for Master Playback by running amixer. 7) Logout of the user's account and back in again. So, what happens? The sound level at logoff is reported correctly at the new login by both Settings -> Sound and amixer. That's a first!! But it isn't always the truth. If the sound level set by the user is < 100% then not only is the lower volume maintained but it is heard to be lower. On the other hand, if the user-selected volume is anything greater than 100%, then the reported values are correct but the audible sound level does NOT change. Amixer seems to know this. In its display it has an innocent little line which reads 'Limits: Playback 0 - 65536'. That actually explains what we are experiencing. I have never found a way to increase the limit for playback but the software seems happy to allow the user to think he is effectively increasing sound levels when in effect the limit in amixer is being obeyed and overrules the wishes of the user. (Damn those troublesome humans, but a little truth-telling on the various displays would be a plus!) Any volume settings below the 100% volume do, as mentioned earlier, attenuate correctly. Could not this be a straightforward patch-free fix, by allowing the user to cap volume levels which seems to have been part of the plan from the beginning? FWIW, I am running a completely up-to-date server with the Nvidia driver acquired in the standard way via rpmfusion, but I'll be happy to provide latest release level details for the alsa and pulse component if it is helpful to anyone else. George
(In reply to George Walsh from comment #12) > Well, here I am one year later on this bug. I've somehow now convinced 'the > ghost in the machine' to maintain a user's sound levels through a > logout/login cycle, or so it would appear, anyway. What I did was: > > 1) Install pavucontrol > 2) Disable flat-volumes in /etc/pulse/daemon.conf by changing the line > reading > ; flat-volumes = yes > with a line reading > flat-volumes = no > REBOOT for good measure. > > Now, for each individual user: > > 3) Log in to that user's account > 4) Invoke pavucontrol > Under the Configuration tab, for 'Built-in Audio, set profile to 'Off' > and for GF108 High Definition Audio Controller, set profile to > 'Digital Stereo (HDMI 4) Output. > Under the Output Devices tab, for the HDMI port, move both front > output > sliders to the farthest right (153% 11.00db) > 5) Invoke Settings -> Sound and under the Output tab select Device > HDMI/DisplayPort 4 - GF108 H.D. Audio Controller and slide volume > level to the far right if it is not already there. > 6) Verify the setting for Master Playback by running amixer. > 7) Logout of the user's account and back in again. > > > So, what happens? > > The sound level at logoff is reported correctly at the new login by both > Settings -> Sound and amixer. That's a first!! > But it isn't always the truth. If the sound level set by the user is < 100% > then not only is the lower volume maintained but it is heard to be lower. > On the other hand, if the user-selected volume is anything greater than 100%, > then the reported values are correct but the audible sound level does NOT > change. > > Amixer seems to know this. In its display it has an innocent little line > which reads 'Limits: Playback 0 - 65536'. That actually explains what we > are experiencing. I have never found a way to increase the limit for playback > but the software seems happy to allow the user to think he is effectively > increasing sound levels when in effect the limit in amixer is being obeyed > and overrules the wishes of the user. (Damn those troublesome humans, but a > little truth-telling on the various displays would be a plus!) Any volume > settings below the 100% volume do, as mentioned earlier, attenuate > correctly. > > Could not this be a straightforward patch-free fix, by allowing the user to > cap > volume levels which seems to have been part of the plan from the beginning? > > FWIW, I am running a completely up-to-date server with the Nvidia driver > acquired in the standard way via rpmfusion, but I'll be happy to provide > latest > release level details for the alsa and pulse component if it is helpful to > anyone else. > > > George Hi George, I think it would be most correct to open a new report against the current Fedora release and likely against pulseaudio with all the details; test cases, etc because adding to this report is likely going to be interpreted as just un-actionable noise, due to the fact that this bug report is closed and you have an updated system you can provide relevant data from. Good luck!