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
