After a buffer underrun the ALSA get_space() function sometimes returned
values larger than the ao had set in ao_data.buffersize. Fix this by
replacing the old check against MAX_OUTBURST by one against
ao_data.buffersize. There should be no need for the MAX_OUTBURST check;
the current MPlayer side should no longer have any constant limit on the
amount of data an ao can buffer or request at once.
The get_space() values larger than ao_data.buffersize triggered errors
in audio decoding causing the current attempt to fill audio buffers to
be aborted. I'm not sure how often that caused behavior noticeably worse
then an underrun already is.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24610 b3059339-0415-0410-9bf9-f77b7e298cf2
ao_mpegpes.c: In function 'init':
ao_mpegpes.c:230: warning: label 'retry' defined but not used
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24376 b3059339-0415-0410-9bf9-f77b7e298cf2
send 0-samples according to the amount of data lost during pause.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23829 b3059339-0415-0410-9bf9-f77b7e298cf2
between common, MPlayer-specific and MEncoder-specific parts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22546 b3059339-0415-0410-9bf9-f77b7e298cf2
AES0 parameter in the device name instead of poking around inside ALSA's
configuration structures. This means that the non-audio bit will be set
even if the user-specified device name tries to clear it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22184 b3059339-0415-0410-9bf9-f77b7e298cf2
be, thus using it like a constant is incorrect.
Move wavhdr initialization to the code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@21266 b3059339-0415-0410-9bf9-f77b7e298cf2
device name.
The setting of the non-audio bit is now done by changing the default
value of the AES0 parameter in the ALSA configuration structures. This
works with user-specified devices, too.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19895 b3059339-0415-0410-9bf9-f77b7e298cf2
immediately instead of continuing with the remaining calls that would
fail anyway because the device or some variable wasn't properly
initialized in this case.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19893 b3059339-0415-0410-9bf9-f77b7e298cf2
header files that happen to have the same name as internal ones.
based on a patch by Vladislav Naumov, vladislav.naumov **at** gmail **dot** com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19426 b3059339-0415-0410-9bf9-f77b7e298cf2
should be there since it now works without the corresponding vo but is
not a particularly good ao overall.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19415 b3059339-0415-0410-9bf9-f77b7e298cf2
this will shut up mplayer -realy-quiet. ao_mpegpes is the first ao that is
tried and will almost always fail (unless you have the right hardware)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19368 b3059339-0415-0410-9bf9-f77b7e298cf2
to the correct (void). Only files in libao2 are affected.
patch by Stefan Huehner stefan AT huehner-org>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18920 b3059339-0415-0410-9bf9-f77b7e298cf2
truncation of output, set flag AOPLAY_FINAL_CHUNK in play call to tell
ao there will be no more data beyond what's in current buffer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18738 b3059339-0415-0410-9bf9-f77b7e298cf2
ao_polyp.c:74: warning: implicit declaration of function âstrcspnâ
ao_polyp.c:79: warning: implicit declaration of function âstrncpyâ
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18491 b3059339-0415-0410-9bf9-f77b7e298cf2
when using a software plugin for JACK/OSS/Polypaudio/Bluetooth/etc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17849 b3059339-0415-0410-9bf9-f77b7e298cf2
improve the reporting of other errors, and don't try to call
snd_pcm_writei() repeatedly when it aborts after a partial write due to
an error.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17622 b3059339-0415-0410-9bf9-f77b7e298cf2
behaviour of the OSS driver. This implies that underruns are not longer
reported.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17621 b3059339-0415-0410-9bf9-f77b7e298cf2
things instead of waiting for the device to become ready. However, just
calling snd_pcm_wait() is identical to blocking mode, so we can just as
well remove support for non-blocking writes.
Besides, the waiting code was never actually used because play() is
never called with more data than reported by get_space().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17620 b3059339-0415-0410-9bf9-f77b7e298cf2
Directly accessing the sample buffer makes sense only when the samples
can be constructed in-place. When the samples are just copied from
another buffer (as is the case with libao2 drivers), the code to copy
those samples is just a reimplementation of snd_pcm_writei(), so we
could as well use that function.
Besides, the current mmap code does not work except in the most simple
cases: it claims to support non-interleaved and complex sample formats,
but treats them the same as interleaved formats and writes to the wrong
memory location.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17617 b3059339-0415-0410-9bf9-f77b7e298cf2
variables, and remove the unused dir parameter from set_xxx_near()
calls.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17576 b3059339-0415-0410-9bf9-f77b7e298cf2
automatically, and remove a call to snd_pcm_drop() because
snd_pcm_close() does it automatically.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17575 b3059339-0415-0410-9bf9-f77b7e298cf2
can call snd_pcm_delay() directly.
To avoid the audio device appearing to be running too fast after an
underrun, ignore any samples that were lost in an underrun.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17574 b3059339-0415-0410-9bf9-f77b7e298cf2
device states, and there is no need to avoid returning a positive value
less than 1024.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17573 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