The mplayer frontend (specifically, mixer.c) needs to know this. If the
audio output doesn't remember the volume across reinitialization, the
frontend will restore the volume settings. There is also the assumption
that the volume setting isn't global in this case (i.e. changing it
won't change the volume of other applications or annoy the user
otherwise).
None of these changes have been tested. I'm guessing that ESD and NAS do
per-connection non-persistent volume settings.
not defined/undefined, use them accordingly.
2) Add ESD definitions to avoid undefined preprocessor directives warnings.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28397 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
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
uncovered while trying to send sound to a remote esd server over a
wireless (11 mbs, just enough to handle to sound) link.
First, the sound was full "ticking" sounds. I found a bug that
prevented the "send the remainder of this block" code from ever being
called - so large chunks of audio were simply being ignored. Fixing
this bug removed the "ticking" from audio streams.
Fixing this bug, however, uncovered another problem - when the socket
buffer was full, doing a blocking write to finish the buffer would take
far too long and would turn video into a chunky mess. I'd imagine this
blocking write would be fine for an audio-only stream, but it turns out
to hold up the video far too much.
The solution in this patch is to write as much data as possible to the
socket, and then return as soon as possible, reporting the number of
bytes actually written accurately back to mplayer. I've tested it on
both local and remote esd servers, and it works well.
Patch by Benjamin Osheroff <ben@gimbo.net>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11620 b3059339-0415-0410-9bf9-f77b7e298cf2
