Vorbis dev - Jul 2003 - optimization to libao audio output autodetection code

Ok, this patch replaces the old patch I sent, and it
does a bit more.

For one, it sorts the linked list of drivers based on
the priority values, highest valued ones coming first.
 That allows the _find_default_driver_id code to stop
looping (break) immediately when it finds a driver
that works, because it already knows it's the working
driver with the highest priority (what it normally
returns anyway).

The advantage to sorting based on priority, is it
gives us some control over what order the drivers are
tested in, because currently the order comes from the
dirent (directory entry), which we AFAIK have no
control over.

So that's an optimization, the other one is what I was
trying before with arts, have it only pass the test()
if arts has the DSP open and give it a higher
priority, so if that all is true, we can select arts
immediately instead of wasting time testing the others
which aren't going to work.  This new patch also does
the same for esd.

All in all, this patch gives us better control over
what drivers have to get tested, and the order they're
tested in, and makes the autodetection a bit faster.

Patch libao-0.8.3-autodetection.patch attached.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libao-0.8.3-autodetection.patch
Type: text/x-diff
Size: 5495 bytes
Desc: libao-0.8.3-autodetection.patch
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20030710/1bbb2a33/libao-0.8.3-autodetection-0001.bin

On Thu, 2003-07-10 at 21:27, David Walser wrote:
> For one, it sorts the linked list of drivers based on
> the priority values, highest valued ones coming first.
>  That allows the _find_default_driver_id code to stop
> looping (break) immediately when it finds a driver
> that works, because it already knows it's the working
> driver with the highest priority (what it normally
> returns anyway).
> All in all, this patch gives us better control over
> what drivers have to get tested, and the order they're
> tested in, and makes the autodetection a bit faster.
Ah, I very much like this patch now.  It should be in CVS by tomorrow
night (after I've had a chance to play with it a bit).


---
Stan Seibert

<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

--- Stan Seibert <volsung@mailsnare.net> wrote:
> Hi, just wanted to let you know that this patch is
> in CVS.  For a second
> I thought I had found some sort of implementation
> issue, but it turned
> out to be a mostly bizarre set of circumstances.
> 
> Apparently the Mandrake version of esd has been
> patched to output
> through arts (yes, very weird), so when I was
yeah, I knew that, didn't know it could be an issue
this big.  It's the reason aRts was given a higher
priority (aka try it first) than esd.
> testing your plugins to
> see if the esd plugin would pass on detection if it
> wasn't holding the
> device, I found that there was a 20 second gap where
> libao would fail to
> find any device.  I thought this was most bizarre,
> until I realized that
> when I used esd purposely (to make it grab the
> device), the following
> happened:
> 
> * esd opened arts connection
> * arts opened alsa device
> * wait 10 seconds:
> * esd releases "audio device" (really connection to
> arts)
> If I try to get the default device here, it failed
> because esd said
> "nope, I don't have the device open" and alsa said
> "nope, I can't open
> the device".  As it turns out, I hadn't built the
> arts plugin.  :)
> * wait 20 more seconds.
> * arts releases the device
Yeah I hadn't thought of not building the aRts plugin.
 I was discussing something else on the Mandrake
Cooker mailing list, a problem I was seeing with libao
only on current Cooker, and he couldn't reproduce it,
turns out only until he built the aRts plugin.  The
problem we're seeing on Cooker is if aRts has the
sound device open, and you let libao do its
autodetection (this is with or without my patch) you
get a segfault.  Tell it explicitly to use aRts and
it's fine.  It seems to die (just watching ltrace)
inside a pthreads call, and I suspect glibc to the
problem, but don't know for sure.  I need to figure
out a way to build libao as a static library and link
it into mpg321 and build it all with -g to see if gdb
can help me, unless you have any better ideas.
> Anyway, not really a problem with your patch since
> for those 20 seconds
> there really isn't any device I can use without the
> arts plugin.  Just
> thought you might be interested in knowing how
> tangled all these audio
> APIs can get.  :)
> 
> Thanks again for the patch.
No problem, thanks for committing it.  I hear you've
committed a NAS plugin too, I'm wondering how it fits
into all of this.
> ---
> Stan Seibert
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.