[linux-audio-dev] Old hat - comparison against windows
david at olofson.net
Wed Jan 31 22:23:57 UTC 2007
On Wednesday 31 January 2007 22:49, Lee Revell wrote:
> On 1/31/07, David Olofson <david at olofson.net> wrote:
> > There are a few hacks for RTAI and/or RTLinux, actually, but
> > AFAIK, nothing for any serious hardware... (I did one myself a few
> > years ago, for RTLinux and AudioPCI cards, IIRC.)
> There's no point these days - the 2.6 -rt kernel can already deliver
> latencies down to the hardware limit.
Yes, but that's not all there is to it.
Jitter reduces the amount of CPU time available for real time
processing. Worst case jitter of N ms means you can't safely use more
than M - N ms per fragment, where M is the fragment period. Triple
buffering or dynamic fragment size may cut you some extra slack in
relation to total latency (same logic as triple buffering with
OpenGL), but this isn't supported by all hardware.
Related to this, making efficient use of multiple CPUs and/or cores
requires much tighter timing than UP processing, unless you can get
away with running multiple independent audio "pipes" in parallell.
The inter-thread sync can be solved with lock free mechanisms, but
that doesn't help much if threads with tight interdependencies get
out of phase due to scheduling latencies.
That said, as you can't use all CPU time on a UP machine anyway, and
as cache issues seem to make multithreaded processing virtually
pointless (with the possible exception of multicore CPUs), it's
entirely possible that there is no real gain in cutting latencies
below what 2.6-rt can provide. I don't know, but it might be worth
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
More information about the Linux-audio-dev