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

Sidik Isani lksi at cfht.hawaii.edu
Mon Sep 30 01:34:00 CEST 2002


On Mon, Sep 30, 2002 at 01:30:32AM +0200, Arpi wrote:
> Hi,
> 
> >   If the environment contains $AUDIOSERVER, it would actually be
> >   reasonable to try "nas" before the native drivers.  Someone running
> >   with that environment variable wants their sound forwarded to a
> >   different host, even if /dev/dsp exists.  Not important if it is
> >   messy to implement this way.  If there's no AUDIOSERVER, I'd suggest
> yes it's messy
That's what I suspected.

> >   moving nas after sdl.  It can slow things down trying to make
> >   socket connections to DISPLAY:8000 and localhost:8000 otherwise.
> 
> what about checking for AUDIOSERVER in ao_nas's init(), and fail if it's
> undefined? or does it work even without it?

  Hmm.  I'm just learning about "nas" myself, but it seems that audio
  servers usually run on 2000 + whatever port the X-Server is using
  (6000 plus the screen number).  If no AUDIOSERVER is set, it uses
  the hostname in DISPLAY and adds 8000 to the number after the ':'.
  So we probably want to keep this standard ability to use "nas" with
  DISPLAY too, but don't want to have everyone pay the cost of an
  attempted socket connection before trying sdl possibly.

  Maybe the plug-in could register itself twice, and a "nas-auto"
  would only try AUDIOSERVER while "nas" remains unchanged.  Kind of
  weird though.  How about this: would there be any way in ao->init()
  to figure out if I'm being called because the user specifically
  selected me (-ao nas), or if I'm being called as a probe?  In any
  case, rather than removing DISPLAY checking completely, I'd vote
  to put nas at the end of the list.

> >   By the way, I've re-done the sync-averaging patch more in the way
> >   you suggested (as a correcting wrapper for audio_out get_delay().)
> >   It is also completely protected by a command line option so we
> >   can look at the patch and be sure it doesn't affect the A/V sync
> >   behavior if you don't give this option.  Maybe this will make it
> >   safe enough to go into 0.90.  But I'll have some other systems on
> >   which to test it by middle of the week.  I'd like to wait until
> >   then before submitting this second try.
> ok, but don't wait too much, i'm about releasing pre9 in a few days,
> and then no new features/changes except fatal (meaning pre10...) or
> trivial fixes, till 0.90 final
> 
> imho send your patch asap, and we'll see how users like it in pre9.

  Ok, thanks.  I haven't synced with CVS in a few days.
  I'll try to post something by tomorrow night then.

Be seeing you,

- Sidik



More information about the MPlayer-dev-eng mailing list