Where 8 channel support is non-trivial (e.g. ao_dsound), at least ensure we
fail gracefully.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29868 b3059339-0415-0410-9bf9-f77b7e298cf2
except for the last chunk.
Should fix high CPU usage reported e.g. here: http://bugs.gentoo.org/show_bug.cgi?id=286020
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29748 b3059339-0415-0410-9bf9-f77b7e298cf2
a constant number of frames. This improves the behaviour at very
small or large sample rates, and gets rid of lots of obsolete code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29549 b3059339-0415-0410-9bf9-f77b7e298cf2
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
Fixes icc warning #188: enumerated type mixed with another type
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27738 b3059339-0415-0410-9bf9-f77b7e298cf2
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
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
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
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
ao_alsa.c:115: warning: suggest parentheses around assignment used as truth value
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17098 b3059339-0415-0410-9bf9-f77b7e298cf2
