When you mute audio, mplayer is supposed to restore the volume controls
on exit. This affects when --softvol isn't used and the audio output
driver volume controls directly affect the system wide volume controls.
This wasn't done in some cases.
Some audio outputs don't provide access to a system-wide mixer control, and
do per-application audio mixing. Further, some of these forget the volume
as soon as the audio device is closed. This can be annoying, because
mplayer will "forget" the volume when playing a new file or when crossing
ordered chapter boundaries. Support restoring the volume on audio
reinitialization if an audio output driver knowingly behaves this way.
(This doesn't change that mplayer never writes any settings into the config
file, including volume settings.)
This commit doesn't yet change any actual output driver to use this code.
Hopefully make some logic in the volume restore code a bit more robust.
Similarly to the last commit, restore the balance setting when switching
to a new file. Unlike the volume setting, balance is always implemented
as filter, so this affects usage without --softvol too.
When --softvol is enabled, the volume set by the "volume" property is
reset when changing to a new file or crossing ordered chapter boundaries.
Fix this by explicitly restoring the volume on audio reinitialization.
Now the behavior with --softvol should be the same as if a system mixer
is used, and the volume should be persistent across file changes.
This also works around an inconsistency with the mute flag. The frontend
assumed the mute flag is persistent across file changes, which was not
true with --softvol.
If not resetting the volume on playing new files is undesired, it can
be avoided by putting volume=100 in the mplayer config file.
Make the outside interface of audio output handling similar to the
video output one. An AO object is first created, and then methods
called with ao_[methodname](ao, args...). However internally libao2/
still holds all data in globals, and trying to create multiple
simultaneous AO instances won't work.
