Bug 1012716 - Set master output channel volume level does not survive a reboot
Set master output channel volume level does not survive a reboot
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: alsa-utils (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jaroslav Kysela
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-26 22:03 EDT by Tony White
Modified: 2015-02-13 08:07 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-10 07:18:45 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
alsa-save systemd service (496 bytes, text/plain)
2015-02-10 07:19 EST, Tony White
no flags Details
alsa-load systemd service (621 bytes, text/plain)
2015-02-10 07:21 EST, Tony White
no flags Details
/etc/alsa/alsactl.conf (749 bytes, text/plain)
2015-02-10 07:24 EST, Tony White
no flags Details
/usr/share/alsa/alsa.conf.d/20-default.conf (121 bytes, text/plain)
2015-02-10 07:28 EST, Tony White
no flags Details

  None (edit)
Description Tony White 2013-09-26 22:03:03 EDT
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.
Comment 1 Rex Dieter 2014-01-30 07:54:31 EST
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
Comment 2 Jaroslav Kysela 2014-01-30 09:22:22 EST
Also note that the pulseaudio can modify the volume after reboot, so it would be good to check the situation without pulseaudio.
Comment 3 George Walsh 2014-02-15 16:36:19 EST
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
Comment 4 George Walsh 2014-03-14 14:33:38 EDT
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
Comment 5 Fedora End Of Life 2015-01-09 14:59:59 EST
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.
Comment 6 Tony White 2015-02-10 07:18:45 EST
(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.
Comment 7 Tony White 2015-02-10 07:19:55 EST
Created attachment 990061 [details]
alsa-save systemd service

Saves alsa volumes before shutdown.
Comment 8 Tony White 2015-02-10 07:21:12 EST
Created attachment 990062 [details]
alsa-load systemd service

Loads saved alsa configuration at boot.
Comment 9 Tony White 2015-02-10 07:24:19 EST
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.
Comment 10 Tony White 2015-02-10 07:28:38 EST
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.
Comment 11 Rex Dieter 2015-02-10 17:30:13 EST
> 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.
Comment 12 George Walsh 2015-02-12 21:30:41 EST
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
Comment 13 Tony White 2015-02-13 08:07:54 EST
(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!

Note You need to log in before you can comment on or make changes to this bug.