github/mpv
1
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-11-18 21:16:10 +01:00
Code Releases Activity
3e59ee25ea
mpv/audio/mixer.h

61 lines
1.9 KiB
C
Raw Normal View History

Add license header to all top-level files missing them. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30471 b3059339-0415-0410-9bf9-f77b7e298cf2
2010-01-31 00:24:23 +01:00
/*
* This file is part of MPlayer.
*
* MPlayer is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* MPlayer is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with MPlayer; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
Identifiers starting with underscores are reserved. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23954 b3059339-0415-0410-9bf9-f77b7e298cf2
2007-07-31 09:04:07 +02:00
#ifndef MPLAYER_MIXER_H
#define MPLAYER_MIXER_H
ups, I missed'em.. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@442 b3059339-0415-0410-9bf9-f77b7e298cf2
2001-04-15 20:37:07 +02:00
options: move mixer.h options to struct
2012-01-21 08:28:07 +01:00
#include <stdbool.h>
softvol, ao_pulse: prefer ao_pulse volume control by default --softvol is enabled by default. For most audio outputs, this is a good thing, as they have either their own (bad) soft volume implementation, or control the system mixer. With ao_pulse, the situation is a bit different: it supports per-application volume (i.e. volume control is not really global). More importantly, ao_pulse uses a rather large audio buffer, and changing the volume with mplayer's volume filter has a large delay. With the native ao_pulse volume control, it's instant, because PulseAudio's audio filtering happens at a later stage in its processing pipeline (inaccessible for mplayer). This means native volume control should really be allowed for ao_pulse, while it's the reverse for other audio outputs. Make --softvol a choice option, and add a new "auto" choice. This is default and will use PA's volume control with ao_pulse, and mplayer's volume filter otherwise (i.e. the old softvol behavior).
2012-09-18 21:41:22 +02:00
enum {
SOFTVOL_NO = 0,
SOFTVOL_YES = 1,
SOFTVOL_AUTO = 2,
};
mixer: reindent/cosmetic changes There should be no real semantic changes. Remove the mixer_setbothvolume macro, as it was unused.
2011-12-26 01:41:35 +01:00
typedef struct mixer {
audio: change external AO interface to "ao_[method](ao, ...)" 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.
2011-04-09 02:03:22 +02:00
struct ao *ao;
audio: untypedef af_stream
2012-11-01 13:33:38 +01:00
struct af_stream *afilter;
New 'Mixer API' with ability to change volume through libaf (this part was written by Reimar Doffinger) and lesser global variables git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12673 b3059339-0415-0410-9bf9-f77b7e298cf2
2004-06-26 11:14:20 +02:00
int volstep;
softvol, ao_pulse: prefer ao_pulse volume control by default --softvol is enabled by default. For most audio outputs, this is a good thing, as they have either their own (bad) soft volume implementation, or control the system mixer. With ao_pulse, the situation is a bit different: it supports per-application volume (i.e. volume control is not really global). More importantly, ao_pulse uses a rather large audio buffer, and changing the volume with mplayer's volume filter has a large delay. With the native ao_pulse volume control, it's instant, because PulseAudio's audio filtering happens at a later stage in its processing pipeline (inaccessible for mplayer). This means native volume control should really be allowed for ao_pulse, while it's the reverse for other audio outputs. Make --softvol a choice option, and add a new "auto" choice. This is default and will use PA's volume control with ao_pulse, and mplayer's volume filter otherwise (i.e. the old softvol behavior).
2012-09-18 21:41:22 +02:00
int softvol;
options: move mixer.h options to struct
2012-01-21 08:28:07 +01:00
float softvol_max;
audio: keep volume level internally (not only in AO) Current volume was always queried from the the audio output driver (or filter in case of --softvol). The only case where it was stored on mixer level was that when turning off mute, volume was set to the value it had before mute was activated. Change the mixer code to always store the current target volume internally. It still checks for significant changes from external sources and resets the internal value in that case. The main functionality changes are: Volume will now be kept separately from mute status. Increasing or decreasing volume will now change it relative to the original value before mute, even if mute is implemented by setting AO level volume to 0. Volume changes no longer automatically disable mute. The exception is relative changes up (like the volume increase key in default keybindings); that's the only case which still disables mute. Keeping the value internally avoids problems with granularity of possible volume values supported by AO. Increase/decrease keys could work unsymmetrically, or when specifying a smaller than default --volstep, even fail completely. In one case occurring in practice, if the AO only supports changing volume in steps of about 2 and rounds down the requested volume, then volume down key would decrease by 4 but volume up would increase by 2 (previous volume plus or minus the default change of 3, rounded down to a multiple of 2). Now, the internal value will keep full precision.
2012-04-09 16:39:01 +02:00
bool muted;
mixer: support native audio driver mute Make mixer support setting the mute attribute at audio driver level, if one exists separately from volume. As of this commit, no libao2 driver exposes such an attribute yet; that will be added in later commits. Since the mute status can now be set externally, it's no longer completely obvious when the player should automatically disable mute when uninitializing an audio output. The implemented behavior is to turn mute off at uninitialization if we turned it on and haven't noticed it turn off (by external means) since.
2012-04-10 03:45:53 +02:00
bool muted_by_us;
bool muted_using_volume;
audio: keep volume level internally (not only in AO) Current volume was always queried from the the audio output driver (or filter in case of --softvol). The only case where it was stored on mixer level was that when turning off mute, volume was set to the value it had before mute was activated. Change the mixer code to always store the current target volume internally. It still checks for significant changes from external sources and resets the internal value in that case. The main functionality changes are: Volume will now be kept separately from mute status. Increasing or decreasing volume will now change it relative to the original value before mute, even if mute is implemented by setting AO level volume to 0. Volume changes no longer automatically disable mute. The exception is relative changes up (like the volume increase key in default keybindings); that's the only case which still disables mute. Keeping the value internally avoids problems with granularity of possible volume values supported by AO. Increase/decrease keys could work unsymmetrically, or when specifying a smaller than default --volstep, even fail completely. In one case occurring in practice, if the AO only supports changing volume in steps of about 2 and rounds down the requested volume, then volume down key would decrease by 4 but volume up would increase by 2 (previous volume plus or minus the default change of 3, rounded down to a multiple of 2). Now, the internal value will keep full precision.
2012-04-09 16:39:01 +02:00
float vol_l, vol_r;
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.
2012-04-09 20:02:27 +02:00
/* Contains ao driver name or "softvol" if volume is not persistent
* and needs to be restored after the driver is reinitialized. */
const char *restore_volume;
audio: restore balance setting after reinit Restore the audio balance setting when the audio chain is reinitialized (also after switching to another file). Also add a note about the balance code being seriously buggy.
2012-04-09 20:06:10 +02:00
float balance;
mplayer: keep volume persistent, even when using --volume Consider: mpv --volume 10 file1.mkv file2.mkv Before this commit, the volume was reset to 10 when playing file2.mkv. This was inconsistent to most other options. E.g. --brightness is a rather similar case. In general, settings should never be reset when playing the next file, unless the option was explicitly marked file-local. This commit corrects the behavior of the --volume and --mute options. File local --volume still works as expected: mpv --{ --volume 10 file1.mkv file2.mkv --} This sets the volume always to 10 on playback start. Move the m_config_leave_file_local() call down so that the mixer code in uninit_player() can set the option volume and mute variables without overwriting the global option values. Another subtle issue is that we don't want to set volume if there's no need to, which is why the user_set_volume/mute fields are introduced. This is important because setting the volume might change the system volume depending on other options.
2013-04-10 19:07:26 +02:00
bool user_set_mute;
bool user_set_volume;
New 'Mixer API' with ability to change volume through libaf (this part was written by Reimar Doffinger) and lesser global variables git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12673 b3059339-0415-0410-9bf9-f77b7e298cf2
2004-06-26 11:14:20 +02:00
} mixer_t;
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.
2012-04-09 20:02:27 +02:00
void mixer_reinit(struct mixer *mixer, struct ao *ao);
audio: fix unmute-at-end logic The player tried to disable mute before exiting, so that if mute is emulated by setting volume to 0 and the volume setting is a system-global one, we don't leave it at 0. However, the logic doing this at process exit was flawed, as volume settings are handled by audio output instances and the audio output that set the mute state may have been closed earlier. Trying to write reliably working logic that restores volume at exit only would be tricky, so change the code to always unmute an audio driver before closing it and restore mute status if one is opened again later.
2012-04-09 21:11:49 +02:00
void mixer_uninit(struct mixer *mixer);
New 'Mixer API' with ability to change volume through libaf (this part was written by Reimar Doffinger) and lesser global variables git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12673 b3059339-0415-0410-9bf9-f77b7e298cf2
2004-06-26 11:14:20 +02:00
void mixer_getvolume(mixer_t *mixer, float *l, float *r);
void mixer_setvolume(mixer_t *mixer, float l, float r);
void mixer_incvolume(mixer_t *mixer);
void mixer_decvolume(mixer_t *mixer);
void mixer_getbothvolume(mixer_t *mixer, float *b);
audio: keep volume level internally (not only in AO) Current volume was always queried from the the audio output driver (or filter in case of --softvol). The only case where it was stored on mixer level was that when turning off mute, volume was set to the value it had before mute was activated. Change the mixer code to always store the current target volume internally. It still checks for significant changes from external sources and resets the internal value in that case. The main functionality changes are: Volume will now be kept separately from mute status. Increasing or decreasing volume will now change it relative to the original value before mute, even if mute is implemented by setting AO level volume to 0. Volume changes no longer automatically disable mute. The exception is relative changes up (like the volume increase key in default keybindings); that's the only case which still disables mute. Keeping the value internally avoids problems with granularity of possible volume values supported by AO. Increase/decrease keys could work unsymmetrically, or when specifying a smaller than default --volstep, even fail completely. In one case occurring in practice, if the AO only supports changing volume in steps of about 2 and rounds down the requested volume, then volume down key would decrease by 4 but volume up would increase by 2 (previous volume plus or minus the default change of 3, rounded down to a multiple of 2). Now, the internal value will keep full precision.
2012-04-09 16:39:01 +02:00
void mixer_setmute(mixer_t *mixer, bool mute);
bool mixer_getmute(mixer_t *mixer);
The audio balance feature implemented with af_pan. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23588 b3059339-0415-0410-9bf9-f77b7e298cf2
2007-06-20 04:26:20 +02:00
void mixer_getbalance(mixer_t *mixer, float *bal);
void mixer_setbalance(mixer_t *mixer, float bal);
ups, I missed'em.. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@442 b3059339-0415-0410-9bf9-f77b7e298cf2
2001-04-15 20:37:07 +02:00
Identifiers starting with underscores are reserved. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23954 b3059339-0415-0410-9bf9-f77b7e298cf2
2007-07-31 09:04:07 +02:00
#endif /* MPLAYER_MIXER_H */
Copy Permalink