[pulseaudio-discuss] Volume Restore

[Marcus Blumhagen]

On Fri, Oct 16, 2009 at 08:46:37PM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Marcus Blumhagen at 16/10/09 12:47 did gyre and gimble:
> >I recently switched to pulseaudio and discovered the very same issue.
> >MPlayer is setting the volume on playback start. I fixed it locally by
> >changing libao2/ao_pulse.c. I also posted this to the mplayer-users
> >mailing list but sadly it got not much attention.
> >
> >Check the link for details and a patch sugesstion:
> >http://lists.mplayerhq.hu/pipermail/mplayer-users/2009-October/077999.html
> 
> This looks interesting. Does mplayer read back the volume from pulse
> later tho'? The patch listed on it's own (without reading the other
> code) would suggest that the value for volume will go out of sync
> with what the volume actually is... I'm not sure if that value is
> used elsewhere anyway.
> 
> But overall, I agree that it should *not* set the volume. The only
> question mark is whether or not there needs to be some extra code to
> read the volume back :)
> 
> I'll try and do some testing...
> Col

Well, I haven´t thought about that, when I changed the code. Actually
I am not really a programmer. In short, I have been using the modified
mplayer version for some days now and haven´t experienced anything
unexpected. 

I can set the volume explicitly on startup by -volume but don´t need
to do so in which case pulse will restore the volume, provided the
responsible module is loaded. If the module is not loaded I get the
volume set to 100%, since mplayer cannot know the last volume when it
was closed. Changing the volume during playback does what is expected
and the OSD reflects the correct volume in that case.

The patch itstelf is a slight change to how the pulse output stream
gets initilaized, so if I am not mistaking here, it makes not much of
a difference regarding the out of sync volume issues, since this only
happens on playback start. So even the unpatched version already needs
to read the volume, at least to represent it in the OSD.

I did look into the code again though and from what I can tell the
volume is always read back from the audio output before a volume
change happens. This is done by mixer_(inc|dec)volume() in mixer.c.
and the corresponding code in ao_pulse is in control(), where the
volume is read from pulse then. And in the latter function the value
of volume is used again.

I haven´t checked what happens to GUIs like smplayer though. I can at
least imagine that the volume slider in such apps can be out of sync,
when you change the stream volume from outside , i.e. in pavucontrol.
OTOH I think in that case it would be out of sync no matter which
audio output is used.


Marcus