mirror of
https://github.com/mpv-player/mpv
synced 2025-02-28 03:10:55 +00:00
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:
parent
94f72b1e59
commit
7a6d26370c
@ -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;
|
||||
}
|
||||
|
||||
|
@ -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;
|
||||
|
Loading…
Reference in New Issue
Block a user