On Sun, 09 Jul 2000 16:50:37 -0700, Tom Pincince
<stillone@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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:10 EST