Messages in this thread | | | Subject | Re: real-time threaded IO with low latency (audio) | Date | Fri, 23 Jul 1999 15:15:41 -0400 | From | Paul Barton-Davis <> |
| |
>> I consider the idea of a single-processor system replacing, say, a >> dedicated Lexicon rack unit or a Quadraverb 20, to be pretty >> silly. > >Why, when it's a "simple" matter of fixing the real time scheduling? Off >course, cache misses and similar problems might suggest that latencies >below 3 ms shouldn't be used for efficiency reasons. That's a user level >choice, though: A little more CPU power, or extremely low latency.
a "real" FX processor can do real-time flanging with a 0.2ms delay. the idea that linux (or beos) for that matter can step into this kind of role is absurd, or close to it.
>> >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. > >For the processing thread, it's a lot less than 5 ms. A lot less, >because signal processing is CPU intensive, and I want plug-ins to be >able to utilize more than a fraction of the available CPU power. There's >hardly no room for cathing up after a stall under heavy load, so this is >very important.
i think (but don't know) that you're wrong. quasimodo does a lot (arguably all) of what you are talking about, and it works the way i describe. if you are in a tight loop reading from the ADC, processing, and then writing to the DAC, the timing i describe is exactly what you want.
>"Average latency" and "maximum latency" are two very different things.
no - latency and jitter are two different things. what we have a problem with is jitter, not latency. the difference is subtle but its important because it affects how you think about solving it.
>> >What is an audio application? >> >> Take a look at http://www.op.net/~pbd/quasimodo/ for my answer to that >> question. > >That's a pretty nice answer! :-) That code will be nice reading, if you >don't mind. ;-)
be sure to get it from CVS. i'm spending a lot of time right now working on tightening down the screws on the real-time FX processing loop.
--p
- 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/
| |