[gst-devel] autoplugging and 0.9
in7y118 at public.uni-hamburg.de
Sun Aug 22 04:31:13 CEST 2004
On Mon, 16 Aug 2004, Andy Wingo wrote:
> On Mon, 16 Aug 2004, Benjamin Otte wrote:
> > Which brings me to another thing we recently discussed on IRC:
> > If we make threading implicit and allow the schedulers to insert new
> > threads (which obviously need queues), how do we guarantee or at least
> > achieve low latency?
> I could be off my rocker, but I don't think multiple threads and low
> latency are achievable together. Multiple threads within the flow of
> data of course; other threads that are truly independent don't affect
> the latency.
> The reason is that locking a mutex, necessary for sharing data between
> threads, is not a bounded-time operation.
> That's not to say that latency will be uniformly poor, or that
> performance will bad. It's just that you stand a good chance of getting
> a latency spike every now and then, possibly causing dropouts.
Yeah, I should have given an example probably:
Take a pipeline like dvdnavsrc ! ... ! xvimagesink (where ... can mean
anything, from loads of processing to just mpeg decoders) that tries to
handle navigation events. If we allow a scheduler to cache arbitrary
amounts of buffers, we'll never know at what timestamp a navigation event
will be handled. If we don't allow schedulers to cache any buffers at all,
we could at least have a good guess as to how long it'll take until the
result of a mouse move is visible on screen.
More information about the gstreamer-devel