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/