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.
- Make it work without sdl-config which adds at least useless or even hurtful
cflags and also does not work for cross-compiling
- If using sdl-config, make it use the CFLAGS we actually use for compiling
instead of something else. Thus #undef main is needed in the test program.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30178 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids a pointless indirection that only obscures what is really done.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27761 b3059339-0415-0410-9bf9-f77b7e298cf2
patch replaces '()' for the correct '(void)' in function
declarations/prototypes which have no parameters. The '()' syntax tell
thats there is a variable list of arguments, so that the compiler cannot
check this. The extra CFLAG '-Wstrict-declarations' shows those cases.
Comments about a similar patch applied to ffmpeg:
That in C++ these mean the same, but in ANSI C the semantics are
different; function() is an (obsolete) K&R C style forward declaration,
it basically means that the function can have any number and any types
of parameters, effectively completely preventing the compiler from doing
any sort of type checking. -- Erik Slagter
Defining functions with unspecified arguments is allowed but bad.
With arguments unspecified the compiler can't report an error/warning
if the function is called with incorrect arguments. -- Måns Rullgård
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17567 b3059339-0415-0410-9bf9-f77b7e298cf2
- assert that the override param is nonzero (zero is not implemented)
- correct return value type to int
based on a patch by Diego
fixes bugzilla bug #342
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17246 b3059339-0415-0410-9bf9-f77b7e298cf2
Patch by Reynaldo H. Verdejo Pinochet <reynaldo at opendot dot cl>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13384 b3059339-0415-0410-9bf9-f77b7e298cf2
when we have found a nicer automatic solution for -af volume.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12715 b3059339-0415-0410-9bf9-f77b7e298cf2
