Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: John Alvord (jalvo_AT_mbay.net)
Date: Mon Jul 10 2000 - 07:06:36 EEST
On Sun, 09 Jul 2000 16:50:37 -0700, Tom Pincince
<stillone_AT_snowcrest.net> wrote:
>>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
The specification of an audio oriented machine can also set
requirements on the hardware. SCSI, particular sound cards, memory.
cpu speed.
john alvord
This archive was generated by hypermail 2b28 : Mon Jul 10 2000 - 07:31:24 EEST