Bug 55262 - If volume was at 0% at shutdown upon reboot it's at 100%.
Summary: If volume was at 0% at shutdown upon reboot it's at 100%.
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: alsa (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poljar
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 75721
  Show dependency treegraph
 
Reported: 2012-09-23 22:55 UTC by Georgiy Treyvus
Modified: 2014-12-26 11:20 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georgiy Treyvus 2012-09-23 22:55:12 UTC
Background from a user perspective:
Generally unexpected sounds annoy me. I thus keep the volume at zero unless I'm listening to music or something in which case I crank it to a comfortable volume using XF86AudioRaiseVolume and then bring it back to zero with XF86AudioLowerVolume afterwards. For a while that worked great. But then this regression came. I'm not the surest when. Perhaps around the time kernel 3.2 was released or a bit earlier. I don't fully recall. Either way the problem has been around a while and is very annoying.

Problem description:
Say the volume is at 0% on shutdown. The next time I turn on the computer it's at 100% and the next thing I have to do is lower it. This is not necessarily tied to rebooting the computer. This same problem also occurs every time I restart alsa/pulse. From here on let my terminal do the talking. Note that after issuing "pulseaudio --kill" I wait a couple of seconds for pulse to respawn.

Terminal output:
[georgiy@PANTHER ~]$ amixer get Master
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 32768 [50%] [on]
  Front Right: Playback 32768 [50%] [on]
[georgiy@PANTHER ~]$ amixer set Master 0%
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 0 [0%] [on]
  Front Right: Playback 0 [0%] [on]
[georgiy@PANTHER ~]$ amixer get Master
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 0 [0%] [on]
  Front Right: Playback 0 [0%] [on]
[georgiy@PANTHER ~]$ pulseaudio --kill
[georgiy@PANTHER ~]$ amixer get Master
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 65536 [100%] [on]
  Front Right: Playback 65536 [100%] [on]
[georgiy@PANTHER ~]$
Comment 1 Tanu Kaskinen 2012-09-24 14:16:35 UTC
I can't reproduce this exactly. Instead of Master jumping to "65536 [100%]", it jumps to "62 [0%]". It shouldn't jump anywhere, it should stay at 0. Maybe the root cause is the same thing that makes the volume go to 100% on your machine.
Comment 2 Tanu Kaskinen 2012-09-24 14:23:08 UTC
One strange thing is this right before the alsa sink is created:

D: [pulseaudio] module-device-restore.c: Database contains invalid data for key: sink:alsa_output.pci-0000_00_1b.0.analog-stereo:null

I think it's printed when module-device-restore is supposed to restore the saved volume for the sink. The device-restore database is freshly created, so it's not a case of some old corrupt data from an old pulseaudio version. There's definitely a bug in module-device-restore.
Comment 3 Tanu Kaskinen 2012-09-24 15:25:14 UTC
module-device-restore fails to load the saved volume, because when the volume is originally set and saved, it's saved for the current port. But when module-device-restore tries to restore the volume, the port of the new sink is not yet known, unless it has been restored too.

The sink port will only be restored if the user has manually changed it. So, a workaround for this problem is to change the sink port to something else and then back, for example with pavucontrol (go to the Output Devices tab and change the Port of the appropriate device).

How to fix this then? pa_device_port should be extended to store the port volume, and then module-card-restore can restore the port volumes. Once the port volumes are properly restored, the sink volume can then be just copied from the port once it has been chosen.

I'm not volunteering to do the fix in the near future. Hopefully someone else will pick up this...
Comment 4 Georgiy Treyvus 2014-02-05 06:06:47 UTC
Sorry for bothering you guys but this is still an issue in February 2014. Also is there any way I can help fix this?
Comment 5 poljar 2014-02-05 13:39:21 UTC
Sorry for not posting info here. Some work has been done to fix this [1], but the patches need further attention[2]. If you like you can take over and fix the remaining issues, if not I'll get to it in the near future hopefully.

[1] http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-April/016995.html

[2] http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-June/017465.html
Comment 6 Tanu Kaskinen 2014-02-05 14:18:12 UTC
If someone does something, please note that my opinion may have changed (again) about how this should be implemented. In the referenced mailing list discussion I proposed that port objects would be created after the pa_card_new() call. I don't think that was a good idea.

Damir, do you remember why we wanted to change the way port offsets are restored? I think the current way is fine (restore in the CARD_NEW hook).
Comment 7 poljar 2014-02-05 15:10:52 UTC
I remember something about it vaguely, but I can't remember the reason, sorry.

Would you mind sharing your new opinion?
Comment 8 Tanu Kaskinen 2014-02-05 15:35:46 UTC
My new opinion is that we should restore the port attributes in the CARD_NEW hook. I just wonder if there's actually some good reason behind the patches that you made that introduce the PORT_NEW hook.
Comment 9 poljar 2014-02-05 15:44:55 UTC
I think i found the relevant thread:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-March/016476.html
Comment 10 Tanu Kaskinen 2014-02-05 16:32:18 UTC
Ok, the motivation for PORT_NEW was probably that module-card-restore needs to know whether the port volume has already been set, and the usual pattern with pa_foo_new_data would help with that.

I would personally prefer a separate hook for setting the initial port volume (not PORT_NEW, if we're going to initialize the volume in pa_card_new() where the port object already exists). The hook could be called PA_CORE_HOOK_PORT_SET_INITIAL_VOLUME. I don't know if other maintainers like this, however.

An example of this kind of a "set initial thing" hook is PA_CORE_HOOK_NODE_SET_INITIAL_ROUTING in the routing patches that have not been reviewed yet: https://gitorious.org/pulseaudio/tanuk-clone/commit/1d047ca24a3200721270bae119855a84f569d5e6
Comment 11 Tanu Kaskinen 2014-03-03 16:26:58 UTC
I want this fixed in 6.0, so I made this now a release blocker bug.
Comment 12 Tanu Kaskinen 2014-03-11 16:14:18 UTC
*** Bug 75984 has been marked as a duplicate of this bug. ***
Comment 13 Raymond 2014-06-04 04:49:58 UTC
as pulseaudio provide calculated software volume even when the sound card has hardware volume


since the combined software and hardware volume need to represent the request volume in the sound preference volume slider, the calculated software volume always has gain or attentutation except when both hardware and software volume are  at 0dB
Comment 14 Tanu Kaskinen 2014-08-17 10:40:47 UTC
I believe this bug has been fixed in this commit: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=e0e6bf687573ea8ee3b6b53f8e44bcb30f4914ec

I noticed, though, that I could still reproduce the bug with the given steps, because there's another problem: module-device-restore doesn't save its database during module unloading, so if pulseaudio is shut down soon after changing the volume, the volume change doesn't get saved (there's a 10 second wait before changes are flushed to disk).
Comment 15 Georgiy Treyvus 2014-08-17 17:49:31 UTC
Thank you all so much for fixing this. Seriously you guys are awesome.

Also I wonder should I report this other issue Tanu described in a separate bug report or is this something you folks are already well aware of and planning to fix:

"I noticed, though, that I could still reproduce the bug with the given steps, because there's another problem: module-device-restore doesn't save its database during module unloading, so if pulseaudio is shut down soon after changing the volume, the volume change doesn't get saved (there's a 10 second wait before changes are flushed to disk)."

Anyway thank you again for this current fix.
Comment 16 Tanu Kaskinen 2014-08-18 11:24:49 UTC
(In reply to comment #15)
> Thank you all so much for fixing this. Seriously you guys are awesome.
> 
> Also I wonder should I report this other issue Tanu described in a separate
> bug report or is this something you folks are already well aware of and
> planning to fix:
> 
> "I noticed, though, that I could still reproduce the bug with the given
> steps, because there's another problem: module-device-restore doesn't save
> its database during module unloading, so if pulseaudio is shut down soon
> after changing the volume, the volume change doesn't get saved (there's a 10
> second wait before changes are flushed to disk)."

That's now fixed too: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=c49c6b75f0bb9c6e99f22eb03217bc539138728d
Comment 17 Georgiy Treyvus 2014-08-18 18:15:34 UTC
Thank you. You guys are awesome.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.