22 Oct
2002
22 Oct
'02
2:47 a.m.
On Mon, 21 Oct 2002, Ivica Bukvic wrote:
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.
The problem is that OSS and ALSA based programs use the block on
read/write metaphor that kills latency. That's why they need to be
ported/rewritten to the non-blocking style. That jack forces the clients
to do so could probably be considered it's greatest contribution.
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
What needs to be done is for someone to implement alsa-server as a jack
client. This has been gone over before, the solution was found
(alsa-server), but no one did it.
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.
If latency is a choice for the user (and often it isn't) then they can
pick their sound server. Jack is a no-compromise low-latency server.
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
This is unnecessary. I often run xmms and ardour at the same time. Xmms
doesn't talk to Ardour or Jack, but it doesn't interfere either. Of
course, I don't hit play while recording or playing in Ardour.
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
But companies write for ASIO. Certain software needs a promise of
low-latency.
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.
Everything is about tradeoffs. The important design decision in jack was
to work in lowlatency. Allowing for higher latency would compromise that
decision.
And that's almost besides the point. You can have higher latencies. I
often run with a buffer of 8192. Horrible latency. But I never see an
xrun.
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?
Well, that really depends on your system. Latency is tricky. Heck,
digidesign only provides support on certain hardware configurations.
You might want to look at PortAudio also, which has jack as an output.
Taybin
--
http://www.piratesvsninjas.com