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.

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.

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...

Sorry for bothering you guys but this is still an issue in February 2014. Also is there any way I can help fix this?

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

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).

I remember something about it vaguely, but I can't remember the reason, sorry.

Would you mind sharing your new opinion?

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.

I think i found the relevant thread:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-March/016476.html

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

I want this fixed in 6.0, so I made this now a release blocker bug.

*** Bug 75984 has been marked as a duplicate of this bug. ***

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

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).

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.

(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

Thank you. You guys are awesome.