More info about jack

[David Bishop]

On Friday 21 February 2003 10:35 am, Neil Stevens wrote:
> On Friday February 21, 2003 09:22, David Bishop wrote:
> > > OK, looking at Jack, they say that they're low-latency and aRts isn't.
> > >  If that's true, then I think aRts (especially that capital R) is
> > > badly named. I hope Stefan is around and reading this thread to
> > > comment on this.
> >
> > Unfortunetly, I am fairly positive it's true.  I don't think, however,
> > that it is a problem for 99% of the users, for the same reason that we
> > don't all need hard-realtime kernels.
>
> Well, I'm of the opinion that everyone who uses Noatun on linux 2.4 *does*
> need Robert Love's preemption patch. :-)

Preemptions or low-latency, yes.  Hard real-time, not really.  I.e., once you 
have no skipping in noatun (and we're there), there isn't really a major 
benefit to making it "even faster", which is what the jackd guys are after.  

> > > > If arts did function as a jack host it could become the end user
> > > > choice since jackd more directed toward professional users.
> > >
> > > Absolutely.
> > >
> > > So, did you want to work on this?  I can't imagine anyone would object
> > > to shipping a plugin that allows the use of jack plugins.
> >
> > Dunno about using plugins, as I don't see a ton (any?) plugins for jack
> > that are all that exciting.  This is a case where jackd is *not* a full
> > arts replacement, as (afaict), it doesn't do any decoding for you, i.e.,
> > it has no PlayObject equivalents, it expects you to decode before
> > getting to it.  Or maybe I'm misunderstanding what you are saying here.
>
> Well, the diagram on the Jack page mentions plugins in the jackd process.

From what I remember, they were just the standard "low pass filter" type 
stuff.  If they get more, maybe I'll look into it (that and one *more* dollar 
and you'll get coffee, too!)

> > Long, long time ago (in this thread), I mentioned that if I ever get my
> > current arts project done, I would look into making it so that artsd
> > could use jackd as an output plugin, like it uses alsa, or oss right
> > now.  So it wouldn't be a case of having a seperate jackd configuration
> > module or anything, just choose it as the output.  This would allow
> > someone using, say, Rosegarden to be able to use jack with it, and
> > other, arts-enabled apps, at the same time.  Now, my promise to look
> > into this and $1 will get you a hamburger at McDonald's, and I'm not
> > expecting you to jump up and down with joy at a (relatively) nameless
> > stranger talking about stuff without code. But there *is* someone
> > interested in this stuff, so I wouldn't dismiss it out of hand :-)
>
> Heh.  But what good would that do us, though, to stick yet another layer
> between arts apps and the hardware?

Nothing.  It does *arts* no more good, to put another layer there.  It does, 
however, benefit users who want to use jackified apps and artsified apps at 
the same time, with the (obvious) caveat that using arts in this manner will 
just add to the latency of those apps, not improve them.  The whole reason 
for me even looking into this is that I would really like to be able to 
listen to my tunes via noatun while working in rosegarden.  I.e., that's the 
itch that I'm scratching B-)

> > *obligatory complaint*
> > Um, the docs on arts really suck :-(  Maybe I'm just spoiled with the
> > great Qt and KDE docs, but it's really disappointing to find that even
> > the headers are poorly commented (for instance, see Arts::Refiller at
> > http://www.arts-project.org/doc/headers/Arts__Refiller.html, and based
> > soley off of that (or anything else on that site), tell me what it's
> > return value is supposed to represent, or what, exactly, is supposed to
> > be in buffer after it returns.  I'm having to figure this stuff out by
> > reading the source to other PlayObjects :-((  (thanks for the pointers
> > to those, by the way.  the corrollary to the "docs suck" complaint would
> > be that the mailing list is responsive)
> > *end of obligatory complaint*
>
> Right, nobody likes the arts documentation, and everyone learns by talking
> to other people and looking at other sources.

(Unspoken in your response): And my whining doesn't actually get anything 
done.  Yeah, I know. :-(

> > I really like arts, I use noatun to listen to my tunes, I use the -ao
> > arts option with mplayer, kmplayer in konq, kmidi to listen to my
> > compositions from Rosegarden.  I'm not here to bury arts, but to praise
> > it B-)
>
> Then how about improving the aRts deficiencies instead of essentially
> giving up and outputting to jack?  :-)

I don't see this as giving up, but as a compatibility measure.  *My* apps, 
assuming they have audio needs, will use arts.  But I can't dictate what 
other people will use (and though rosegarden has an arts-output, its use is 
discourage by the devs, and my impression is that it is unmaintained; and it 
is just one example of an app that uses jack, there are others).  Also, I've 
found that a good way to learn a project is by trying to extend it, via a 
plugin or something else.  Once I have my mind completely wrapped around how 
it all works, maybe I'll dive into the internals. (a final $1, and now you 
have delicious fries ;-)

-- 
"Yousa steala precious from meesa!" - Jar-Jaromir

D.A.Bishop