22 Oct
2002
22 Oct
'02
1:59 a.m.
On Mon, 21 Oct 2002, Paul Davis wrote:
> >So why, having studied the docs, am I completely stumped with jack?
It
>refuses to
play. I don't consider any solution based on a piece of
software
> >_I_ can't operate suitable for general use.
>
> JACK *isn't* intended for general use, and i get tired of > that it should be. there are lots of people
working on solutions for
> "general use". JACK is intended for people who are serious about
> audio. in particular, although it might work with crappy consumer
> audio interfaces, its not intended to do so. if you can't run JACK
at
> 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.
> there's not much we can do about that except
> to point you at kernel adjustments (like hdparm) and ask that you
> check other mailing lists to see if your audio interface, video
> interface, etc. are known to be horrible in some respect.
>
> JACK is not yet finished, and it has some definite usability issues
> that need to be resolved. but it is not, and i hope will never be
> (primarily) a general purpose sound server.
>
> alternatively, there might be a bug in JACK. perhaps you can help us
> find it.
>
> --p
>
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
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)
[either due to fact the apps are not being constantly updated any more,
or maybe the developers are skeptical about porting to Jack when there
are so few apps ported into its framework], while a few PRO apps (i.e.
Ardour) will.
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
free. Most of us in Linux strive to make everything work under it both
hardware-wise and software-wise, as well as being backwards-compatible.
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
to make a choice whether to use jack-based apps or work with oss drivers
coupled with some kind of artsd high latency daemon (that at least let's
you do multiple opens in software or select mic inputs on the mixer --
something that is not the case with Alsa + artsd). I do not want to have
my artistic ideas limited by the questionable software limitations. Do
you?
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.
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. 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.
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? If it
isn't user-friendly, who will want to deal with it, except for Linux
die-hard fans (one of them being myself)? Even you mentioned your
intentions of selling ardour-installed computers. Who will want to deal
with all this configuration crud? People in studios do not want to hear
about jackd -d alsa or hw:0,0 crap, nor do they want to buy a computer
that will do only ardour. They just want it to work, and while working
on pro audio software, they may still want to hear audible alerts that
their laptop is running out of battery or that they have a pending
appointment. Instead they will get mind-boggling errors, such as
/dev/dsp resource busy, and similar junk...
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
every product, just to cover all that can possibly go wrong during the
jack init.
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
worse. Jack should (and does!) allow for higher latency work so that it
can accommodate itself to crappier audio hw.
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?
That being said, I have been at least somewhat convinced that Jack is
possibly the way to go, and after some thinking, I've decided to attempt
porting RTcmix into the Jack framework. Only time will now tell whether
this was worth it or not. Yet, comments like these make me again
reconsider my move before I dig into some serious coding with jackd and
use my precious time on stuff that simply may not take off...
Regards,
Ico