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

[Tobias Diedrich]

Sidik Isani wrote:

>   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?

As long as only play() is called all Au.* calls are made from within the
event_handler. Only when you Start, Stop or Pause the threads may get in
the way of each other. Maybe we should add a mutex there, but it seems
to work well enough (libaudio should be threadsafe to some extent now).

>   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?

Good idea :-)
I also noticed some stuttering problems that were solved by making the
client_buffer bigger than the server_buffer.

>   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.)

The startup glitches should be gone with my patch...

>   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.

I'd be interested in having a look at it :-)

>   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

I still think it's a non-issue.
No one firewalls connections from localhost and if you're running on a
remote display it is either on your LAN (and at least I only firewall on
my border gateway) or you are running X over a ssh session and it would
try to connect to localhost (which can reasonably be expected not to be
firewalled).

> "nas:auto", ... native drivers, ... "sdl", ... ("nas" again?)

init() has a flags parameter. I think it would be best to add a flag that
this is a probe.

-- 
Tobias Diedrich							PGP: 0x9AC7E0BC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20021003/afd54394/attachment.pgp>