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

[Sean]

On Sun, 26 Nov 2006 16:15:00 -0500
Paul Davis <paul at linuxaudiosystems.com> wrote:

> this means that you never call ioctl, so i guess you never select a data
> format or data rate. interesting. and i guess you never care about
> latency. and presumably you certainly don't care whether your app can
> route date to or from other audio apps, which is a rather Unix-y thing
> to want. suprising given your appreciation of the open/read/write/close
> model.

There are a lot of applications that don't really care about audio
latency.. beeps and alerts for program events for instance.  And usually
there is no desire to route such sounds to other apps.  While I know that's
not the class of app you're interested in, and really isn't even the type
of app gstreamer is designed for, it does account for a lot of programmer
interaction with audio; and open/read/write/close is sure a nice simple
way to get that job done.

[...]
> it works for a highly restricted set of applications that just happen to
> be the ones of interest to the largest number of users. it works *much*
> less satisfactorily for everything else.

Yes, as I took his point, it wasn't that everyone should use the O/R/W/C
model, it's that it would be nice if modern audio interfaces didn't
require an API that was an order of magnitude harder to wire up for
programmers with only passing interest in audio.

[...]
> why is it that i have a jack-related inbox that is full of comments from
> people telling me that JACK is the simplest, easiest to use audio API
> they have ever come across? 

Well, IMO gstreamer isn't the simplest audio API ever created.  But if
JACK is as easy as you say, then why is it not appropriate as a general
purpose sound server?  Why keep the focus only on pro audio?

[...]
> so presumably you think that CoreAudio, whose API is twice the size of
> JACK's and involves massively more complexity, also sucks? 

Starting that debate surely can't lead to forward progress in this
discussion.

> the arrogance of *nix developers just astounds me. we have a platform
> that has sucked, absolutely sucked, for media developers and users since
> the beginning of time (bar a few versions of IRIX), and you want to hold
> up the steaming pile of crap that we've put up with till now as an
> example of how to do it right? why can't we learn from the experiences
> of developers who have been hugely more productive and written vastly
> better applications (for the most part; there are horror stories) in
> different environments and with different APIs?

You're obviously a bit frustrated, and I don't blame you for that.  But
the preceding paragraph makes you sound a bit arrogant.  There's no reason
to slam Linux or its developers, there's no way it can help your cause.

> in case my tone in misinterpreted, please don't think that i believe
> that everyone should be using JACK. in fact, i've resisted quite a few
> overtures, especially from Ubuntu, to make JACK into the "server for
> everyone", because it was never designed to be that. however, having
> *all* media apps built around an API that reflects the collective
> intelligence of all developers, not just open source folk on linux,
> would get us to a place where all apps can interoperate, share audio
> data when appropriate, and interact with any of a number of well
> designed back ends.

It sounds to me that if your above appraisal is correct, then JACK
_should_ be used by everyone.

Personally, I'd like to see JACK well supported by GStreamer.  But it
sounds like there are technical limitations of GStreamer (push model)
that prohibit that from happening easily.  It would be nice if you're
interested though to submit patches and support GStreamer/JACK
integration.

All the best,
Sean