Subject: Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
On Wednesday, October 3, 2001, at 08:09 AM, Paul Davis wrote:
>> On Karl's paper of latency measurements there was mentioned that the
I think I said in the paper that one of the major problems was IDE and
> for example, even in 2.4.0, with the low latency patch, it was
If you hit them hard enough :)
Karl
>> should I get SCSI interface and systems for low-latency work? Also
This archive was generated by hypermail 2b28
: Wed Oct 03 2001 - 17:18:49 EEST
From: Karl MacMillan (karlmac_AT_mambo.peabody.jhu.edu)
Date: Wed Oct 03 2001 - 17:17:40 EEST
>> low-
>> 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,
>
> this is not strictly true. the IDE drivers (and devices) are the worst
> 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.
>
the other reason that we didn't get different results with the
low-latency patches was because of the simplicity of the load generation
programs. There simply isn't enough research and development of
cross-platform load generation tools, so we had to create our own tools
and didn't have enough time to create something that could really stress
the system. Of course it was enough stress to cause problems under
Windows 2000!
> 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).
>
>> could you
>> explain why Windows system with IDE (with busmastering
>> drivers/interface) and
>> ASIO drivers work well enough?
>
> The Linux ones will work well enough when tuned correctly, and
> 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).
>
> SCSI is preferable for every reason, except one: cost.
>
>> Last, could someone write a FAQ for this list. What is JACK?, where is
>> it
>> needed?, can I use JACK with ALSA API? etc. questions are still a
>> little bit
>> open to me.
>
> JACK is the name for an idea previously called LAAGA, an acronym for
> "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.
>
> JACK is an API that solves this problem. It also, and quite
> 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.
>
> If an application uses a callback model, and even better, if it uses
> 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.
>
> --p
>
---
Karl MacMillan
Computer Music Department
Peabody Institute of Johns Hopkins University
410-659-8108 ext. 1239
mambo.peabody.jhu.edu/~karlmac
karlmac_AT_peabody.jhu.edu