[MPlayer-dev-eng] Re: -ao list brings up a Q: best -ao order?

[Sidik Isani]

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,

- Sidik