Subject: Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
>On Karl's paper of latency measurements there was mentioned that the low-
this is not strictly true. the IDE drivers (and devices) are the worst
for example, even in 2.4.0, with the low latency patch, it was
>should I get SCSI interface and systems for low-latency work? Also could you
The Linux ones will work well enough when tuned correctly, and
SCSI is preferable for every reason, except one: cost.
>Last, could someone write a FAQ for this list. What is JACK?, where is it
JACK is the name for an idea previously called LAAGA, an acronym for
JACK is an API that solves this problem. It also, and quite
If an application uses a callback model, and even better, if it uses
--p
This archive was generated by hypermail 2b28
: Wed Oct 03 2001 - 15:06:03 EEST
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Oct 03 2001 - 15:09:53 EEST
>latency patches have actually little effect and the reasone for bad latency on
>some systems is actually IDE. Could you actually tell as more about this,
offenders, but they are far the only place in the mainstream kernel
where the kernel could block a runnable task for a (very) long time.
possible to cause scheduling delays of 30-50-1000! msecs by hitting
the VM and disk subsystems (e.g. a 4-process C++ compile while running
Ardour).
>explain why Windows system with IDE (with busmastering drivers/interface) and
>ASIO drivers work well enough?
combined with a low latency patch. Presumably, the Windows ones are
already tuned properly, and Windows had a better design for mid-range
latency than Linux (they both failed in the low-latency case,
however; this is where the low latency patch came in).
>needed?, can I use JACK with ALSA API? etc. questions are still a little bit
>open to me.
"Linux Audio Application Glue API", and now standing for "Jack Audio
Connection Kit". There is a basic problem with audio+MIDI apps on
Linux at this time, which is that they are not able to exchange data
with each other in situations where low latency is a system
goal. There are systems (aRts, MidiShare, parts of alsa-lib) that
allow data sharing, but not when the latencies get down below 20ms.
importantly, drastically simplifies the programming of audio
applications. Applications that use JACK do not need to know anything
about audio hardware. They do not interact with it directly in any way
whatsoever. All they do is provide a few callbacks to the server they
connect with; the primary callback is responsible for producing and/or
consuming a specified amount of data whenever it is called. This is a
"callback" model, and is extremely different from ALSA, OSS, and
several other audio APIs. It is, however, very similar to Apple's
CoreAudio, Steinberg's ASIO, the PortAudio library, and most plugin
APIs.
JACK's callback model, then it can send and receive data to and from
not only audio h/w, but other applications, and do so robustly with
latencies in the 1-5msec range.