22 Oct
2002
22 Oct
'02
1:29 p.m.
> all, you
basically have a box that wouldn't run an ASIO device
driver
> under windows or macos.
So, in essence Jack is yet another ASIO wannabe. If I wanted ASIO, I'd
be working on Windows or MacOS. What about making it more like Core Audio on steroids
where everything
can be low latency, or high latency, where USER HAS THE CHOICE? This
"Jackd is only for pro's" sounds too much like Apple die-hard fan
zealotry to me, something that I readily detest.
the reason for not doing this is that there isn't manpower to do it. i
am focused on JACK as the engine for a set of apps that i want to be
able use (and i want others to be able to use them) in pro audio, real
time, low latency environments. i don't have the hours (or the cash)
to support the development of a "joe user" sound server. if you do,
then please join the development team and help us out.
of good PRO apps (contrary to your definition of
OSS-based "toys" in one
of your previous e-mails) do not, and will not support it (i.e. RTcmix)
RTcmix, as fabulous of a program as it is, doesn't meet my definition
of "pro audio". actually, "pro audio" is a bad term. i should stick
with stuff like "studios operated as profit-making entities and/or
real time performance with a mixture of electronic and acoustic sound
sources". i'll call SOPME/RTP from now on, OK?
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
1) who said "linux is supposed to be all inclusive"? who?
2) there has never really been much of an oss vs. alsa debate. i have
never seen anyone suggest that oss was better than alsa, merely
that it was expedient to use it because it was there. well,
from 2.5/2.6/3.0, alsa will just "be there" too. so i suspect
that that particular debate is about to evaporate, though alsa's
continued support for the OSS API will not make it happen
too quickly.
3) the esd/artsd thing was resolved in favor of artsd by the GNOME
crew. KDE was already going with artsd.
4) gstreamer has nothing to do with JACK - its an architecture for
streaming data *within* a program.
Yet, in this case if the audio app does not support
JACK, then it's
either a "toy" or basically whomever wants to use it is screwed and has
i never said that not supporting JACK makes something a toy. i noted
that most of the audio applications for linux are (1) written to use
OSS and (2) are toys. there are thousands of links to such programs on
dave's pages. the toys are fun, and often very useful. however, they
are not viable candidates to act as the basis of SOPME/RTP for most
people.
If you really want the JACK to take off, then you
should look not only
as kai has noted, most of the apps i care about already have JACK
support. from my point of view, its already moderately successful.
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.
how about this as alternatives to arrogance?
* 3 kids, including one grumpy and irritable teenage boy, and
two girls who fight endlessly.
* a studio/office under construction
* a house still requiring some basic stuff after moving in
* a long list of bugs and TODO's for my primary software project
* hardly any income (a few US$100's) ever derived from
from linux audio work so far
* 2 CD's of live performances to mix down
* training for ultra-distance cycling racing
* sleep, food, music, sex and books
why should i be doing *anything* for "users" who aren't interested in
paying me, aren't interested in what i'm interested in, and keep
telling me they want things that i can give them but don't like the
package it comes in?
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
ardour, close jackd, and only then start xmms, and then after 10 minutes
do all that in reverse? Why couldn't xmms simply connect automagically
to jackd by jackd detecting simple oss-open-dsp-resource call?
because the OSS API is so deeply *FUCKED* and makes this really hard
to do without user intervention!!! how many times do i and others have
to repeat this?
why don't you just spend $US60 on a decent audio interface that
supports hardware multiopen, and stop looking for software solutions?
the trident cards are nice, simple, reliable and cheap. 32 hardware
stereo streams.
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
just like they won't touch ProTools TDM with a 20 foot pole despite it
being certified for only a couple of wintel based systems and it
requiring custom audio interfaces and other specific stuff?
just like they won't develop for MOTU's MAS, despite it being a 100%
proprietary solution that works only for MOTU systems?
just like they won't develop develop for ASIO, despite only certain
audio interfaces having ASIO drivers?
That's what is wrong with Jack and that's why
you are getting so many
requests to do the obvious. Comments like these only make the situation
i'm not here to do what you feel is obvious. i'm here to do what i
think is the right thing to do and what satisfies my needs and plans
the best. if you want to influence me then paypal is a few clicks
away, but otherwise, exhortations about what users need will not
accomplish very much.
--p