Messages in this thread | | | Subject | Re: real-time threaded IO with low latency (audio) | Date | Fri, 23 Jul 1999 02:20:53 -0400 | From | Paul Barton-Davis <> |
| |
>> 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/
| |