Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Mon Jul 10 2000 - 02:50:37 EEST
>It's no good testing it with my workload! It has to be tested with
>yours. So please, get down and get testing. There isn't a lot of time.
This is *the* key issue here. Simply saying that audio apps require an
OS with sub 5 ms latency is incomplete and potentially misleading. I
feel that pro quality audio on regular Linux is achievable, combined
with some non-radical optimizations and common sense. I've been doing
it for years on mac and windows. The way we accomplish this is by
dedicating the box to audio, disabling all non-essensial background
tasks, and generally avoiding anything that might cause the OS to become
too busy while we are actually recording. Being closed platforms, there
are relatively few areas for user-defined optimizations, but the results
are truly impressive. I have gone *years* without a single dropout on a
68040 mac running system 7.5.1. This is the idea behind the DDT list.
When Juhana raises the issue of deleting large files as being too
important to qualify as a DDT, I find this to be misleading. While it
is true that audio apps generate lots of large temporary files that must
be deleted, it is not true that file deletion and recording must happen
simultaniously. Common sense dictates that a serious recordist have a
sufficiently large hard disk to tollerate the temporary storage of
useless files, and it seems easy enough to design a recording app that
only allows file deletes when the app is not actively recording. The
recording app only needs guaranteed minimum latency while it is actively
recording. Latency is a non-issue at all other times.
>> Lets talk about 7 ms latency only -- 4 ms is useless information in
audio
>> software which has to be 101% reliable. That is poor compared to
earlier
>> results 2.5 ms. Or can audio input-output latency between A/D & D/A
be
>> somehow less than 7 ms?
>
>If I recall correctly, the 7msecs was due to starting the X server, and
>to switching consoles.
This is a perfect example. Simply begin recording after the rest of the
system has settled down, and don't make any changes while the recording
is in progress. Problem solved.
RT performance is only mandatory in serious recording scenarios. Pro
recordists are happy to dedicate the use of the box to *audio only*
during recording and are not going to play games or read emails at the
same time, on the same box. Suggesting that Linux must meet sub 5 ms
latency requirements in the general case is simply untrue, and may lead
some to the incorrect conclusion that the problem can't be solved with
regular Linux. I don't want to see that happen. Paul's open letter
brought the attention of some very tallented kernel developers to our
little corner of the universe, and I feel that we owe them the courtesy
of defining as narrowly as possible the specific areas where audio apps
really do need minimum latency, to admit that truly professional
recording will require an optimized and patched kernel for the present,
to be sincerely thankful even if only 1 or 2 latency optimizations make
it into the standard kernel, and to recognize that Linux has been
evolving for years without the need to address the issues associated
with desktop audio. Eventually as streaming media becomes more common
on the net and Linux on the desktop also advances, the design criteria
for good audio and good Linux will merge, but this may be 1-2 years
off. The important thing to remember is that Linux is already a good
thing and quality audio is possible, even if it isn't mainstream.
Here is a possible stratigy for identifying the key OS optimizations
that would result in the greatest improvements in audio latency with
the fewest changes to the overall kernel.
1) Identify the services of audio apps that truly have mission critical
latency requirements.
2) Identify the OS services that are absolutely necessary for an audio
app (all aspects of the app, not just the RT aspects).
3) Identify the components of the OS that are not a part of (2), that
can generate busy-ness on their own even if they are not called by the
audio app or by other kernel components for the purpose of satisfying
the audio app, and that can be safely deactivated/removed.
4) Create a hypothetical minimalist kernel that contains everything
from (2) and has had everything from (3) deactivated or removed.
5) Identify the components of kernel (4) that will be generating
busy-ness simultaniously with audio apps while they are providing
services (1).
6) Organize the list of components from (5) in order of latency
contribution.
7) Starting from the top of list (6), identify which components are
most fixable / least likely to introduce instability in general kernel.
I feel that I am qualified to address only item (1). Here I go.
There are four main areas where audio apps require mission critical
latency guarantees; recording files to disk, playback of files from
disk, processing audio data prior to playback (includes mixing multiple
files, input from soundcard, and fx plugins), and sound synthesis. The
computer can be configured to perform as a dedicated box serving any one
or combination of these functions. It is not reasonable to assume that
reconfiguring of these core functions can be done on the fly without
dropouts. For example one may want to use the box as a RT synthesizer or
fx processor in a performance setting and choose to load all unit
generators at the beginning then spin down the hard disk to eliminate
the noise. Here latency requirements *may* be easily met because there
is no disk i/o and no dynamic loading of modules. If the performer
suddenly feels that the music is so great that he wants to record it, it
is not a reasonable design criteria to expect the box to output audio to
the soundcard without a dropout while simultaniously starting up the
hard drive, opening the recording app, and performing file allocation.
I could go on in great detail, and I am willing to do so if anyone finds
this sort of thing valuable, but I am not sure if this discussion is
apropriate here.
Continued upon request.
Tom
This archive was generated by hypermail 2b28 : Mon Jul 10 2000 - 03:17:28 EEST