22 Oct
2002
22 Oct
'02
10:54 a.m.
On Mon, 21 Oct 2002, Ivica Bukvic wrote:
And as long as you view JACK as that, it will have a
very small user
base and hence very small pool of audio apps that will support it. All
this will lead to the fact that, no matter how good JACK is (or is
supposed to be), it will be always a questionable solution, since a lot
I think that JACK will become a huge success not because of the
server technology, but because of the applications. FreqTweak and
Meterbridge are two very good examples of this. If these apps
had read from /dev/dsp and wrote to /dev/dsp, they would have been
interesting acquaintances, but it would have been difficult to actually
use them in real work. But now with JACK, they are tools that you can
really _use_!
Few more apps like this and every Linux audio developer is going to be
very tempted to port their app to JACK.
Mark my words, JACK's going to be big. :)
This will create an unnecessary polarization in an
already heavily
fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs.
gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and
Gstreamer already has JACK support btw.
If you really want the JACK to take off, then you
should look not only
forwards, but also backwards, and find a relatively viable solution
(even if it is at the expense of the latency) that will work with 1000+
decent apps that have not been ported to JACK framework, thus leaving
the issue of latency for the user to choose.
This can be done, but we need someone to do it. I've already posted
a message with a proposed design for an OSS-to-JACK gateway. But I
don't have time to do this myself and I cannot force anyone else to do
it either. What can I do? But I'm not too worried about this. I'm quite
sure someone will do this sooner or later.
And if the only explanation to this problem is
"they need to port their
apps to JACK", while there is no effort to meet the user needs at least
half-way by offering an easy interfacing for apps that may not be ported
to JACK in the recent future for whatever reasons, then I see that as
sheer arrogance.
Well, please consider our side. We are trying to solve a problem that
enables a new level of co-operationg between audio apps (see
http://eca.cx/laaga )... This work is not finished yet. If you go and read
recent jackit-devel messages from the archives, not everything is going
just fine and dandy. We (especially Paul) have had to do enourmous amount
of work to get where we are now and there's still work left. There are
still issues that we don't know for sure how to solve and so the work has
to continue. If this is arrogance, so be it. I really don't know how to
reply to you here.
I am not only interested in using Ecasound, Ardour,
FreqTweak, and Pd for my music making purposes, neither is a majority of
other Linux users.
Btw, it's many more than that:
Alsaplayer
gstreamer
icsound
iiwusynth
MusE (since 0.6.0pre1)
Rosegarden
Rtsynth
Spiral Synth Modular
... note that this list contains almost all lad "heavy-weights". I've
never seen this level of co-operation between - some even directly competing -
Linux audio projects, and it's a very exciting development!
Case and point, I may want to use ardour, but if I
take a break and want
to listen to some mp3's on an un-jackified player (such as xmms, for
instance), how user-friendly would it be to have to save session, close
Use alsaplayer and let xmms authors know why you made the choice.
do all that in reverse? Why couldn't xmms simply
connect automagically
to jackd by jackd detecting simple oss-open-dsp-resource call? If it
Because nobody has implemented 1) JACK-plugin for xmms, 2) JACK OSS
gateway. We'd like to see both, but cannot force anyone to do them.
Neither will the commercial companies want to touch
jackd with a 20-foot
pole if there will be an aura of limited hw it works with (that
automatically limits a pool of people that may potentially purchase an
app) and in addition requires a 100-page FAQ section to be shipped with
Let's see about that. :)
What is yet to be determined is for example why am I
getting xruns all
over the place after having jackd run for 10 minutes even at very high
buffer sizes and having it sit idle for most of those 10 minutes?
Yes, that's why we are not working on OSS-to-JACK gateways. There's still
work to be done in the core functionality.
--
http://www.eca.cx
Audio software for Linux!