On Wednesday 31 January 2007 22:49, Lee Revell wrote:
> On 1/31/07, David Olofson <david@email-addr-hidden> 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 --'
Received on Thu Feb 1 04:15:01 2007
This archive was generated by hypermail 2.1.8 : Thu Feb 01 2007 - 04:15:01 EET