[gst-devel] autoplugging and 0.9

[Andy Wingo]

Hey Wim,

That was a pretty cogent email. We like you for a reason ;)

I only have one point I'm unclear about...

On Tue, 2004-08-24 at 14:08 +0200, Wim Taymans wrote:
> > Applications that require low latency and low jitter (any live 
> > processing of audio, video, etc.) fundamentally cannot be implemented 
> > with a system that has implicit queues.  Strict control over latency is 
> > only possible with pipelines engineered from the ground up to use no 
> > queues, passing all data immediately from element to element.
> 
> I understand the issue and I'm going to state that given the right set
> of elements, queues/threads are not going to be insterted at all. Also
> note that an element can select a loop, a chain or a get function based
> on how it connects to the peer element. Also note that loop based
> elements typically require a decoupled processing when not connected to
> an 'obeying' element.
> Also note that the implicit queue would only have 1 buffer, just to pass
> to the other thread after a thread switch. 

I have pipelines with lots of loop elements, because they have many
possible sinks. I say possible because any one can be disconnected, and
the element will run properly. It's because the element has to check
that the pad is disconnected that it has to have a loop[0].

What I wanted to note was that these elements operate at a constant data
rate. Their caps locks them into a uniform buffer size as well. One
buffer in, one buffer out. Thus, they need a single-buffer pen on the
pads (think about the parallel-connection case). The idea of a mutex on
each one of these pens is really unattractive. How does your scenario
treat such pipelines?

[0] Alternately one would have to connect to ::linked signals, changing
the scheduling of the element according to the connected state. I
planned to do this at some time, although opt doesn't handle it yet I
don't think.

Regards,
-- 
Andy Wingo <wingo at pobox.com>
http://ambient.2y.net/wingo/