The mixer frontend code can now make use of a proper system mixer mute
toggle, if the audio output driver supports it.
The consequence is that, if support is available, mplayer will no longer
temporarily set the system volume to 0 if mute is enabled.
Generally, the code now deals with the following combinations of available
AO features:
- software volume control forced by user (--softvol / soft_vol flag)
=> if enabled, never touch the "hardware" controls
- "hardware"/driver volume control available (whether
AOCONTROL_GET/SET_VOLUME works)
=> if not available, enable volume controls by enabling softvol
- "hardware"/driver mute control (AOCONTROL_GET/SET_MUTE)
=> if not available, emulate by setting volume to 0
- whether the volume+mute controls are kept or not when the AO is closed
(indicated by ao->no_persistent_volume)
=> if not persistent, restore the volume/mute next time the AO is opened
Before this commit, the mute state was only reset when either mute was
explicitly cleared, or the volume was changed via mplayer controls. If
the volume controls are connected to the system mixer, and the system
mixer volume is changed otherwise (e.g. with alsamixer), the mute
setting was inconsistent.
Avoid this by checking the volume. If the returned volume is not 0, the
mute flag is considered invalid. This relies on system mixers always
returning a volume of 0 when mplayer has set the volume 0.
Possible caveat: if the audio output's volume control don't return a
volume of exactly 0 after 0 was written, enabling mute basically won't
work. It will set the volume to silence, forget the previous volume, and
report that mute is disabled.
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.
wm4
Uoti Urpala
diego
reimar
zuxy
alex
attila
pontscho
anders
arpi_esp
gabucino