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

[Benjamin Otte]

On Sun, 26 Nov 2006, Paul Davis 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.
>
FWIW, ESD has data format and rate selection in the open() call. OSS might
need an ioctl or it uses 44100 S16 stereo by default, not sure.
As a comparison, ALSA requires a set_buffer_size call or it might use a
2048 bytes big buffer and then I end up with stuttering audio. If I were
just writing my little app, I'd not even know what that means and would
have given up by then.

> 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?
>
I don't care a single bit if it's pulling, pushing, sneezing or otherwise
doing stuff, as long as it's dead simple to use. Let me repeat that: It
doesn't matter how perfect your application is, unless getting started is
really simple.
And it's really hard to get such an API working, but unless there
is one, noone starts using your ap unless he's really serious about it.
(This is preobably why GStreamer has no simple encoder/transcoder
applications btw - it's really hard to write one)

>         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.
>
Surprisingly, neither my CD player, my MP3 decoder, nor my sound cards
seem to have had contact with audio programmers. Or maybe you live in a
different world than I do.

> so presumably you think that CoreAudio, whose API is twice the size of
> JACK's and involves massively more complexity, also sucks?
>
Considering I wasn't able to find a 10-line code file to output an audio
stream with CoreAudio in my 5 minutes of googling, I'd say that it does
indeed suck.
Btw, for ALSA the first link was this:
http://equalarea.com/paul/alsa-audio.html#playex
which, apart from the huge lot of setup commands, is reasonably short to
get started.


I'm not trying to tell you that there's any technical reason why JACK is
bad.
The only thing that sucks about JACK is that getting started is extremely
complicated compared to lots of other sound outputs. And as long as that
is the case, noone will take JACK as the first choice for audio output
unless they write their app for JACK.


Benjamin


PS: The pull model used by non-blocking file descriptors is perfectly
fine. ESD and OSS support that model.