[MPlayer-dev-eng] Re: -ao list brings up a Q: best -ao order?
lksi at cfht.hawaii.edu
Thu Oct 3 10:00:19 CEST 2002
Hello Tobias -
I will try your buffer changes to ao_nas.c soon and let you know
how it works for me. It might take a few days. I did get a few
error messages from libaudio now and then, especially at startup.
I thought it might have been due to the way two different pthreads
make Au() calls at the same time. If that's what happens, is it OK?
Other than the inefficiency of the memcpy's and memmoves, I noticed
one other problem with the buffering scheme: The buffer size ends
up being a bit small for audio modes with many channels or high
sample rates. If we do it in terms of time, what do you think is
reasonable? Always being able to buffer, say, 1/2 second of audio?
I wrote a new ao_nas.c from scratch a few days ago. I won't post
it here right now, because it doesn't belong in a stable release.
It has only inconsequential differences (no startup glitches, but
they were not so bad ... faster and simpler buffering scheme, and
not dependent on pthreads, no extra memcpy's and no locking needed.)
I wrote it to learn how NAS is supposed to work. I *use* yours,
and the stock mplayer. If you want to tweak NAS more in the future,
you might want to have both modules handy for experimenting and
comparing performance, so that's why I mention it.
On Thu, Oct 03, 2002 at 01:42:53AM +0200, Tobias Diedrich wrote:
> > DISPLAY too, but don't want to have everyone pay the cost of an
> > attempted socket connection before trying sdl possibly.
> Did you test the impact of the connection attempt ? It seems unnoticable
> here. In the simple case it is connecting to the local host, which means
> libaudio looks for a socket in /tmp/.sockets/. And if it tries a tcp
> connection it will get the connection refused immediately.
> The other case is with either AUDIOSERVER set (in which case it's the
> users fault if the server is not there and the connection attempt takes
> some time) or a remote DISPLAY (And here again the host is known to be
> up, so the connection refused should come back nearly immediately).
I was thinking the same thing as Rich before he posted it (about
the firewall). I'd say, if AUDIOSERVER is set, try to make the socket
connection, but don't do it based on DISPLAY unless "-ao nas" was given.
Since we can pass parameters after the driver name, what about having
ao_nas check whether it was called as "nas:auto" or just "nas"?
Then the probing order could be
"nas:auto", ... native drivers, ... "sdl", ... ("nas" again?)
And "nas:auto" just returns right away if AUDIOSERVER is not set
but "nas" tries harder? I still don't really mind typing the extra
options. I guess it depends on how user-friendly/clever/mind-reading
mplayer wants to be.
Be seeing you,
More information about the MPlayer-dev-eng