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
post-recording fixup by changing the initialisation value of
data_length. This fixes it.
based on patch by Olivier Galibert <galibert@pobox.com>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9278 b3059339-0415-0410-9bf9-f77b7e298cf2
it has a temporary length of 0. It is more logical to
write an infinite length. (sox does this)
patch by Alain Daurat <daurat@tiscali.fr>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9027 b3059339-0415-0410-9bf9-f77b7e298cf2
for ao_data.bps calcualtion - hence fscked up av sync if soundcard didn't
support a number of channels or audio format.
patch by Balatoni Denes <pnis@coder.hu>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@8604 b3059339-0415-0410-9bf9-f77b7e298cf2
broken)
- arts server always expects 16-bit sound in little endian byte order, even
in the case the artsd server runs on a big endian machine. Make sure that
mplayer's audio filters convert the samples into one of the arts supported
sound formats.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@8577 b3059339-0415-0410-9bf9-f77b7e298cf2
