Subject: Re: [linux-audio-dev] the alternate API for LAAGA: its problems
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Jul 11 2001 - 18:44:25 EEST
In message <CJEKIDIANBGFILNCOHJMIEHFCGAA.richard_AT_muse.demon.co.uk>you write:
>A heads-up for you all to let you know that I've just started building an
>alternative API to LAAGA (in case you care). As posted before, LAAGA doesn't
>seem the right approach to me - it seems to be more of a
>framework/application than an API.
well, thats partly because the whole idea is useless unless it can be
shown to perform adequately. we could create any API we want, but
unless we can demonstrate an implementation with adequate performance
characteristics, its no better than aRts or even esound.
hence the initial versions coming with a sort-of-working server/client
codebase to demonstrate the performance characteristics.
the API is entirely contained in laaga.h, just as LADSPA is contained
in ladspa.h. the rest of the files i have made available are
implementations of that API, nothing else. LADSPA did not require much
of the "host". LAAGA is useless unless the host/server/engine can
perform adequately.
>BTW, I'm very eager to have a look at GStreamer in more detail because this
>is one of the approaches I'm trying to reconcile.
I strongly suspect that GStreamer will have the same problem as GLAME
does. You can configure the graph so that it will stall or do the
wrong thing, or both. As Richard Guenther concisely observed, although
"it" (whatever that is) may appear to be a data-driven graph, it
really is not. The graph is driven by a timer that runs endlessly, and
all nodes *must* run on every timer "tick". If you use an approach
in which the flow of data from A->B is what drives B, then the moment
nothing arrives at B, you may have problems if there are "outbound"
connections from B.
This is a subtle point that took Richard and I several days to get to.
--p
This archive was generated by hypermail 2b28 : Wed Jul 11 2001 - 18:45:24 EEST