summaryrefslogtreecommitdiffstats
path: root/mixer.c
diff options
context:
space:
mode:
authorUoti Urpala <uau@mplayer2.org>2012-04-09 21:02:27 +0300
committerUoti Urpala <uau@mplayer2.org>2012-04-11 03:50:31 +0300
commit87dad2a4704b2fb0f983d5cb665a065437288d35 (patch)
treee457d371a271e9fd669b4633d41ec7384ef912c3 /mixer.c
parent157a6c1e8343cf0d174e6f9edee441bfefebe578 (diff)
downloadmpv-87dad2a4704b2fb0f983d5cb665a065437288d35.tar.bz2
mpv-87dad2a4704b2fb0f983d5cb665a065437288d35.tar.xz
audio: restore volume setting after AO reinit if needed
MPlayer volume control was originally implemented with the assumption that it controls a system-wide volume setting which keeps its value even if a process closes and reopens the audio device. However, this is not actually true for --softvol mode or some audio output APIs that only consider volume as a per-client setting for software mixing. This could have annoying results, as the volume would be reset to a default value if the AO was closed and reopened, for example whem moving to a new file or crossing ordered chapter boundaries. Add code to set the previous volume again after audio reinitialization if the current audio chain is known to behave this way (softvol active or the AO driver is known to not keep persistent volume externally). This also avoids an inconsistency with the mute flag. The frontend assumed the mute status is persistent across file changes, but it could be similarly lost. The audio drivers that are assumed to not keep persistent volume are: coreaudio, dsound, esd, nas, openal, sdl. None of these changes have been tested. I'm guessing that ESD and NAS do per-connection non-persistent volume settings. Partially based on code by wm4.
Diffstat (limited to 'mixer.c')
-rw-r--r--mixer.c27
1 files changed, 27 insertions, 0 deletions
diff --git a/mixer.c b/mixer.c
index 0c92447c62..b231563026 100644
--- a/mixer.c
+++ b/mixer.c
@@ -76,11 +76,17 @@ static void setvolume_internal(mixer_t *mixer, float l, float r)
{
struct ao_control_vol vol = {.left = l, .right = r};
if (!mixer->softvol) {
+ // relies on the driver data being permanent (so ptr stays valid)
+ mixer->restore_volume = mixer->ao->no_persistent_volume ?
+ mixer->ao->driver->info->short_name : NULL;
if (ao_control(mixer->ao, AOCONTROL_SET_VOLUME, &vol) != CONTROL_OK)
mp_tmsg(MSGT_GLOBAL, MSGL_ERR,
"[Mixer] Failed to change audio output volume.\n");
return;
}
+ mixer->restore_volume = "softvol";
+ if (!mixer->afilter)
+ return;
// af_volume uses values in dB
float db_vals[AF_NCH];
int i;
@@ -197,3 +203,24 @@ void mixer_setbalance(mixer_t *mixer, float val)
af_pan_balance->control(af_pan_balance,
AF_CONTROL_PAN_BALANCE | AF_CONTROL_SET, &val);
}
+
+// Called after the audio filter chain is built or rebuilt.
+void mixer_reinit(struct mixer *mixer, struct ao *ao)
+{
+ mixer->ao = ao;
+ /* Use checkvolume() to see if softvol needs to be enabled because of
+ * lacking AO support, but first store values it could overwrite. */
+ float left = mixer->vol_l, right = mixer->vol_r;
+ bool muted = mixer->muted;
+ checkvolume(mixer);
+ /* Try to avoid restoring volume stored from one control method with
+ * another. Especially, restoring softvol volume (typically high) on
+ * system mixer could have very nasty effects. */
+ const char *restore_reason = mixer->softvol ? "softvol" :
+ mixer->ao->driver->info->short_name;
+ if (mixer->restore_volume && !strcmp(mixer->restore_volume,
+ restore_reason)) {
+ mixer_setvolume(mixer, left, right);
+ mixer_setmute(mixer, muted);
+ }
+}