RE: [linux-audio-dev] Re: image problem

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] Re: image problem
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Tue Oct 22 2002 - 15:50:54 EEST


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!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Oct 22 2002 - 16:03:35 EEST