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

[Paul Davis]

On Sun, 2006-11-26 at 14:27 +0100, Benjamin Otte wrote:
> On Fri, 24 Nov 2006, Paul Davis wrote:

> You know, when I write an audio application, I use OSS first. Why? Because
> with OSS I can do open(), write(), close() and that's all I need to know.

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.

> And it works.
> That's why people like OSS so much. It's simple and works. So every app
> under the sun can output to OSS. Same for ESD.

this is just not true. my rough guess is that roughly half of all
pro-audio-ish apps have no OSS support. it might even be more than that
at this point. 

moreover, these open/read/write/close apps cannot be ported to any API
that uses a callback model: i.e. every API under the sun except the
linux hacks based on an open/read/write/close model.

if open/read/write/close is so wonderful (and i have to admit to being
quite a defender of it in the past), why isn't it used for video?

> We all agree that both OSS and ESD suck. But they have a super-simple API
> that works most of the time. 

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.

> So people are happy when they start with
> their project and use them. And as long as it works, there's no need to
> reengineer stuff.

but it doesn't work! 

> Last time I wanted to use JACK (actually for writing a GStreamer plugin),
> I had to know about threads, callbacks and whatnot. You're making it
> really HARD to use your stuff. 

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? 

there are dozens of programmers with very little audio programming
experience who have cooked up all kinds of cool little apps that would
be much, much harder to do with an OSS-style API, not to mention the
fact that the only way you can possibly do inter-app audio with OSS is
via an appalling LD_PRELOAD hack that still doesn't work very well.
JACK's attractiveness to developers are that it:

	a) presents an abstraction that all but eliminates all details related
to audio hardware. moving data to/from hardware is indistinguishable
from moving data to/from other apps (and in some cases, within an app). 

        b) forces all participants to use a single data format which
happens to be the format used by 99% of all audio programmers in the
world (32 bit floating point). the 1% that don't are generally writing
consumer/desktop multimedia on linux. the rest - all plugin developers,
all DAW developers and the rest - have realized that the benefits of
using 32 bit float outweighs any inconvenience. and by removing format
negotiation from graph entry, applications are actually much easier to
write.

        c) removes all uncertainty about data flow rates. JACK tells you
what to do and when to do it. your application doesn't need to do
anything else (unless it wants to).

> And for all I care, it doesn't buy me
> anything. So I decided I don't care a single bit. Unless you bait me with
> a dead simple API, I won't care.
> And you will probably have to write your plugin yourself.

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

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?

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.

--p