[linux-audio-dev] Old hat - comparison against windows

[David Olofson]

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 
some experiments...


//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  --'