[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