>On Karl's paper of latency measurements there was mentioned that the 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. for example, even in 2.4.0, with the low latency patch, it was 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). >should I get SCSI interface and systems for low-latency work? Also 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
