lkml.org 
[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: real-time threaded IO with low latency (audio)
Date
From
>> All they ask is that the
>> operating system never deny them resources if they want to use them
>> and such use doesn't interfere with or require the cooperation of any
>> other subsystem and/or process. That means "CPU hungry", not
>> "absolutely constrained by timing issues".
>
>I'd say both. In order to be usable for professional audio (live in
>particular), these applications NEED to meet EVERY deadline. If there
>can be occational drop-outs when doing reasonably low latency
>processing, I'm going elsewhere.

If the subsystem approach was implemented, and your task is the sole
task with SCHED_FIFO priority, there will never be a drop-out
unless you exceed the CPU's capacity to generate audio samples.

>Until now, dedicated DSP hardware has been the way of doing what
>Audiality will do. Without hard real time, that won't change. The whole
>idea with this hard real time engine is to enable low latency processing
>without external hardware. It's NOT the average audio API, or
>whatever... That part still belongs in soft real time user space.

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.

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

it depends on what you mean by "any defined time". if a SCHED_FIFO
task is *not* running, and an interrupt occurs, then my sense of the
kernel code is that you are *guaranteed* that it will be scheduled to
run immediately. if the timer interrupts aren't frequent enough for
you, you need some other source of interrupts. for these purposes,
those of the soundcard itself work pretty well.

running without SCHED_FIFO and a 5ms latency c/o the fragment size I
request, more than 99% of all (10's of thousands of) write(2)'s to the
soundcard on a mostly quiescent dual PII-450 system complete in 5ms
+/- 0.05ms, measured using the pentium cycle counter (20nanosec
resolution approx). With SCHED_FIFO, the numbers get even better. How
does this work ? Because every time the soundcard interrupts us to
tell us we had a buffer boundary crossing, the SCHED_FIFO (and even
the SCHED_OTHER if the system is quiescent) task is woken up if its
asleep and run immediately. Since I "asked to be woken" every 5ms,
things keep rolling along very nicely.

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

>What is an audio application?

Take a look at http://www.op.net/~pbd/quasimodo/ for my answer to that
question.

--p


ps. sorry for misnaming your project.

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

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans