> I can do 5ms-latency real time FX processing (on a dual system, to be
> honest) with an interpreted language fronted by a complex GUI, using
> the current kernel. There are no dropouts if it runs SCHED_FIFO and
> you leave the GUI alone.
>
> I consider the idea of a single-processor system replacing, say, a
> dedicated Lexicon rack unit or a Quadraverb 20, to be pretty
> silly. However, using a dual processor system, and binding a DSP-like
> thread to one of the processors has a lot of promise, and I'm pretty
> close to doing this once i get Tim's pset patches installed.
Ok, but not everyone has 2 CPUs and
most of us own UP machines, but want the low-latency features,
which are not hardware limits actually.
>
> >Yep, I know, and fixing that might be enough. However, is that enough to
> >guarantee that a real time task will get control within any defined
> >time? I want figures. Hard, real, reliable figures.
I think the can't give a mathematical proof, of upper-bound latencies,
that's why I created my latencytest benchmark.
Running this benchark with stressing the machine as much as possible,
for a long time , and getting NO DROP outs means a RELIABLE RT APP for me.
Call it hard-realtime, soft-realtime , firm-realtime, but what matters
is if the deadlines are meed under high system load or not.
>
>
> This is what I mean by latency not being a problem. The difficulty
> arises as soon the system is no longer quiescent: the kernel starts
> grabbing locks, and the SCHED_FIFO thread gets shut out for several
> msecs.
several = hundreds , in the DMA=off disk mode even thousands ...
:-)
but preliminary tests with a short patch from Andrea Arcangeli,
which reschedules processes after writing blocks to disk,
show nice improvements in the sync mode and dma=off mode,
I will post some figures soon.
This is bad for all of us. One reason why BeOS is a
> "multimedia" OS is that they recognized that the old idea of what an
> application "does" is wrong (i.e. many "modern" applications do 98% of
> their I/O to the video card and/or a soundcard).Lock-taking to protect
> what would have historically been universal (or at least heavily worn)
> paths through the kernel is now often just an impediment to timely
> execution. Yes, the scheduler still needs some global locks, as does
> the VM/MM system, but very else little else should be guarded in the
> way it is now. Everyone on l-k knows this - its just a big task to
> change it.
Ok fully agree,
but the BIG QUESTION is : are the ALSA / kernel developers REALLY interested
in this spinlocking problem, or is this VERY LOW PRIORITY ?
"Ok we are aware the problem , we will work on it when we get time (in 1-2
years), but actually we have much higher priority tasks , like keeping up with
the MINDCRAFT benchmarks."
:-))
I think it this problem will not be fixed soon ( <1 year) , then Linux will
miss it's chance as a MULTIMEDIA OS.
And that's not compatible with the term "world domination".
:-)
I'm just curious how AMIGA plans to solve these issues ,
using a RT-Linux scheme or a firm-real-time scheme ala KURT ?
I think under QNX, this would be very easy,
just run the audio driver, and your RT app at higher priority, than
other driver et voila. (one of the advantages of microkernel)
:-)
RT Linux sounds nice to me, but without memory-protection,
runnnig audio-plugins, becomes very dangerous (look at DirectX),
if there is a bug, the poor Linux box gets down.
At least I would prefer, a crash of the audio engine, which you can
restart again.
And I agree with Paul, a MIDI sequencer or soft-syth is an app ,which need
to make systemcalls AND must run with some time constraints.
Some plugins could run in the Audiality context,
but other parts of the program must run as soft-REAL time app,
and it would be nice if the soft-realtime part stays under the 5ms mark all the
time.
comments ?
regards,
Benno Senoner
E-Mail: sbenno@gardena.net
Linux scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/