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
printfs converted to mp_msg, thanks to adland <adland123@yahoo.com>
gcc 3.4 fix, undefined label at end of case statement
default device is now 'default' instead of hw:0,0. so users are able to
set their own defaultdevice (dmix) in asoundrc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12466 b3059339-0415-0410-9bf9-f77b7e298cf2
added Motif hints memorizing before switching to full screen because
WM can modify decorations of the app window
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12097 b3059339-0415-0410-9bf9-f77b7e298cf2
Works with multiple videos at the same time and even
when NAS does not control the mixer or it is unavailable.
Show buffer underrun hint only once and add missing linebreaks.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12023 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
> ao_data.bps=channels*rate;
> if(format != AFMT_U8 && format != AFMT_S8)
> ao_data.bps*=2;
fallback config, before patch:
> ao_data.bps=ao_data.channels * ao_data.samplerate;
since we forced the format to S16_LE in fallback, we should double bps
to be consistent with an original config of the same settings.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11512 b3059339-0415-0410-9bf9-f77b7e298cf2
Based on Bernard Leak's mail <bernard 4t brenda-arkle.demon.co.uk>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11001 b3059339-0415-0410-9bf9-f77b7e298cf2
If the sound channel is already busy the async open fails and returns
-EBUSY. There's no need to try to open it synchronously as it will block
mplayer till the sound channel is released.
(Granted there's a very slight chance your sound device happen to be
freed between those two calls but it's not the common case).
The behavior is changed by this oneliner to match the ao_oss behavior
(disable sound if the sound device is busy).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@10899 b3059339-0415-0410-9bf9-f77b7e298cf2
