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

On Wednesday 31 January 2007 22:49, Lee Revell wrote: 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 --'