mixer: prefer AO softvol control over volume filter

This partially reverts earlier decisions, when I thought it would
always be better to prefer the audio volume filter over the AO's,
because the AO's relies on the underlying audio-API, which could
be broken or exhibit unusual behavior (like it happened with ao_dsound).

However, since the audio buffer can be quite large (500 ms), and we
don't attempt to flush & refilter the audio on volume changes, always
prefer AO volume control (as long as the AO mixer doesn't control the
system mixer).

Also document what the mixer.c related AO fields mean (hopefully not
too brief).
This commit is contained in:
wm4 2013-02-06 22:11:06 +01:00
parent 94f72b1e59
commit 7a6d26370c
2 changed files with 3 additions and 2 deletions

View File

@ -34,6 +34,7 @@ static void checkvolume(struct mixer *mixer)
if (mixer->softvol == SOFTVOL_AUTO) {
mixer->softvol = mixer->ao->per_application_mixer
|| mixer->ao->no_persistent_volume
? SOFTVOL_NO : SOFTVOL_YES;
}

View File

@ -102,8 +102,8 @@ struct ao {
bool probing;
bool initialized;
bool untimed;
bool no_persistent_volume;
bool per_application_mixer;
bool no_persistent_volume; // the AO does the equivalent of af_volume
bool per_application_mixer; // like above, but volume persists (per app)
const struct ao_driver *driver;
void *priv;
struct encode_lavc_context *encode_lavc_ctx;