[gst-devel] JACK and GStreamer, from the horse's mouth

[Lennart Poettering]

On Wed, 29.11.06 12:17, Andy Wingo (wingo at pobox.com) wrote:

Hi!

> On Tue, 2006-11-28 at 22:14 +0100, Lennart Poettering wrote:
> > Instead I would argue that the pull model actually has negative
> > effects. It is very difficult to marry a system like Gstreamer (which
> > already does its own threading) with the way threading is handled by
> > the pull API. Why? Because you need to pass the audio data between the
> > gst-handled thread and the api-handled thread. That passing requires
> > buffering.
> 
> This is not necessarily the case. Please see my mail:
> 
>   http://article.gmane.org/gmane.comp.video.gstreamer.devel/16728
> 
> Specifically, there is no reason that activating a jacksink's pad in
> pull mode must start a GstTask. We can allow the jack thread to drive
> the pipeline, in the pure-pull case anyway. Otherwise we make a jacksink
> with GstBaseAudioSink's default behavior of starting another thread
> separated by a ring buffer.

Oh, I am sorry. Didn't know that.

Anyway, GStreamer should be merely an example. I am sure other
multimedia systems do have the problem. (Isn't Xine threaded as well?)

Seems as if you saw that problem coming and made sure that GST became
flexible enough to deal with that. However I fear that other projects
are not necessarily that clear sighted. ;-)

Sorry for the confusion. 

Lennart

-- 
Lennart Poettering; 0poetter [at] informatik [dot] uni-hamburg [dot] de
ICQ# 11060553; GPG 0x83E23BF0; http://www.stud.uni-hamburg.de/users/lennart/