[gst-devel] (fwd) Re: [linux-audio-dev] the alternate API for LAAGA: its problems
Andy Wingo
apwingo at eos.ncsu.edu
Wed Jul 11 21:55:32 CEST 2001
What do folks say to this? some notable messages from the original lad
thread that was referenced by Paul can can be found at
http://www.eca.cx/lad/2001/Jun/0347.html,
http://www.eca.cx/lad/2001/Jun/0359.html, and
http://www.eca.cx/lad/2001/Jun/0361.html.
----- Forwarded message from Paul Davis <pbd at Op.Net> -----
> From: Paul Davis <pbd at Op.Net>
> Subject: Re: [linux-audio-dev] the alternate API for LAAGA: its problems
> To: linux-audio-dev at music.columbia.edu
> Cc: "Richard W.E. Furse" <richard at muse.demon.co.uk>
> Date: Wed, 11 Jul 2001 11:44:25 -0400
> Reply-To: linux-audio-dev at music.columbia.edu
>
[snip]
> >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
>
----- End forwarded message -----
More information about the gstreamer-devel
mailing list