[music-dsp] Low-latency OS
sbenno at gardena.net
Sat Aug 12 15:52:54 EDT 2000
just to clarify the latency things on Linux for non-linux insiders:
(eg these reading the linux-audio-dev and/or linux-kernel mailinglist)
On kernel 2.2 the lowlatency patches achieve about 2.1msec latencies
using an buffer of 3x128 bytes.
This under very heavy load.
(I have done some maniacal tests like firing up 10 fractal generators, a few
tasks which copy 100MB around the disk, find / which basically scans every dir
for files, videocard GFX benchmarks,
and copying the contents of two cdroms in two separate cdrom drives
to the HD)
All the above SIMULTANEOUSLY.
Not to mention that my latencytest tool artificially wastes 80% CPU
during each audio fragment write, in order to simulate a softsynth/hdrecoder
heavily loaded with DSP computations.
As for the the user-friendly stuff:
there are RPM packages of the lowlatency-kernel available,
that means with one single command ( rpm -i yourkernel.rpm) you
can install the lowlatency kernel without any hassles of kernel
patching, configuration and compilation.
The lowlatency features aren't in the main kernel yet because
it is not implemented in a "clean" way (basically it adds rescheduling
points within critical kernel routines, eg. those which do not return
to userspace for long time)
That means for now until a clean solution is found (from a programming elegance
POV), we have to install the lowlatency kernel manually, but using the
precompiled packages, this is a trivial task.
And of course endusers do not care about "programming elegance"
what they want is to run their audio software with 2-5msec latency without
any dropout or skip.
A few of the linux folks are working on the lowlatency patch for the upcoming
And it may even be that future linux distributions will allow you to install the
lowlatency-kernel at installtime, if you chose so.
(A few kernel paranoids would say that the current lowlatency patch decreases
the performance by 1-2%
but this is nonsense, because audio folks will be happy to trade 1-2%
performance loss for rock-solid latencies.
As for windows: you CAN achieve low-latencies: just provide special soundcard
drivers and use ring0 kernel programming and IRQ hacks,
while on linux we need only a simple userspace thread like this :
(which runs with RT privileges and mlocked memory to avoid non-determinism
-compute_audio_fragment() ( read from ram, or generate some data using DSP
write() audio fragment to audio device
And should this 2msec audio latency thread crash, no problem it will just dump
core and the rest of the system will remain totally untouched,
while I am not so sure what happens in this case using ring0 programming on
On Sat, 12 Aug 2000, Ben Loftis wrote:
> speaking about hardware DSP vs software (PC based) DSP, Josh wrote:
> 2. No operating system. If you read the linux-dsp mailing list,
> there is a constant discussion of issues regarding latency,
> process scheduling, disk access times etc.. all because the
> operating system isnt quite geared to real time processing.
> Unless you have the deep skills to modify your operating system,
> there is not much you can do. If you are planing to develop
> for Windows - there is nothing you can do.
> Whereas on a DSP board, you have full control of the system
> and each application can be tailored to your needs - with no
> Don't forget to mention BeOS! It's free, it runs on your hardware
> (probably) , it's a pleasure to code for, and it's "geared to real time
> processing", which Linux and Windows ain't!
dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
More information about the music-dsp