Subject: Re: [linux-audio-dev] present state of affairs with streaming frameworks
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Jul 01 2001 - 12:37:28 EEST
>I'd like to pose a question to those in the know: What is the difference
>between LAAGA (or the goals of LAAGA) and GStreamer?
GStreamer is, according to its website, a developer's tool for
building self-contained applications that feature processing graphs
and streaming media.
LAAGA is an API and a server to facilitate connecting multiple
applications so that they can share data and avoid the typical
interactions with audio interface h/w. An application would not be
expected to use LAAGA internally to handle a processing graph.
As far as I understand GStreamer, it doesn't offer any support for
real-time out-of-process "graph nodes", which is a basic requirement
for LAAGA. Its does have a more sophisticated streaming model
including support for parallelization and so forth. In this sense,
GStreamer must also be compared to GLAME, which is significantly more
mature than GStreamer at this point, though not really a developer's
tool as much as an application.
I would have to leave the GStreamer folks to comment on whether their
graph model shares the properties that Richard and I discussed here at
some length recently. GLAME's model will fail to produce any output
when some upstream connections are broken, which at least a couple of
LAD folk felt was user-unfriendly at the very least.
You could easily write an application that used GStreamer for its own
internal graph processing, but used LAAGA to connect to other
applications and some audio h/w. This is in fact my desired goal for
LAAGA - we're not concerned too much about the internal design of an
application (other than requiring it use a callback approach), we're
just providing a mechanism for connections and proper real time
scheduling of clients.
The primary comparison with LAAGA is aRts, which does some similar
things and in a more general way (using an RPC system with network
capabilities). however, aRts doesn't support out-of-process clients in
a way that is likely to be as reliable for low latency situations, and
may not work very well in low latency situations at all without a bit
of work on its core engine.
--p
This archive was generated by hypermail 2b28 : Sun Jul 01 2001 - 12:42:22 EEST