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

Christian F.K. Schaller christian at fluendo.com
Fri Nov 24 13:21:00 CET 2006

To elaborate a bit on this. I think one could say we switched
development philosophy a bit from 0.6/0.8 to 0.10. In the 0.6/0.8
scenario we tried to create plugins for everything under the sun with
the idea that offering more plugins would bring more application
developers. This only partially worked and the problem was that we got a
huge amount of plugins which nobody actually used and thus they had a
lot of bugs and bitrotted over time. At the same time working on all
these plugins took away time from the plugins actually being used
causing them to be of lower quality than they could have been.

In 0.10 we have tried to instead focus on improving the plugins that are
used and work on new plugins as application developers request them or
supply them. This has meant better working applications and improved
reputation of the framework. Sure if someone comes along now and wants
to use Jack for sound output they have a quite a bit of work to do, but
at least they know that most of the plugins available today are quite
solid and well tested.

So until someone either starts writing a GStreamer application which has
Jack output as a priority I don't see this changing. Also with the work
happening in the distributions to try to move away from the situation
with a separate system for normal and pro audio I am not sure how much
pressure there will be for a resolution here long term. Seems the
distro's prefer a MacOSX like situation with one system for both targets
instead of having to maintain a separate 'pro' ecosystem.


On Fri, 2006-11-24 at 10:00 +0100, Wim Taymans wrote:
> On Thu, 2006-11-23 at 19:54 -0500, Paul Davis wrote:
> > So, in a couple of weeks, I will be at the OSDL DAM-3 meeting to discuss
> > multi-media again. As the (primary) author of JACK and Ardour, and as
> > recent Linux jukebox user, I've been looking around at the current state
> > of things. I've read the mailing lists, and I do not understand why
> > GStreamer does not have a functional, maintained JACK sink (source too,
> > perhaps). JACK is the simplest API around, so unless GStreamer is still
> > hampered by a push model - I was under the impression that you guys
> > switched to a pull model sometime not so long ago - I don't understand
> > why its been so hard to get a JACK sink to stick around. Would anyone
> > care to enlighten me?
> Very simple: nobody has bothered to port/maintain it, there have been
> requests to make the sink functional again but that's usually not enough
> to get something going.
> Technically we allow sinks in pull mode (as we always have done since
> 0.6, or so) and the optimal way to implement an audiosink is when the
> lowlevel API supports pull mode. It's also a lot of additional work to
> make sure that all decoders/demuxers support pull mode so that you can
> build a pipeline that works entirely pull based.
> Wim 
> > 
> > --p
> >

More information about the gstreamer-devel mailing list