Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Alexander Ehlert (alexander.ehlert_AT_uni-tuebingen.de)
Date: Mon May 14 2001 - 01:56:23 EEST
Hi,
> just for reference sake, those of us interested in real-time systems
> with latencies on the order of 2.5ms and below have no more than 1.3ms
> to process an entire audio block. if "low" includes, say, 5 threads,
> you're proposing on the order of 10% of the total cycles available for
> processing be dedicated to inter-thread operations.
Hmm, I'm proposing nothing actually :) I just telling you my experiences.
Anyway, the latency comes from the use of pipes, but richi(co-author) told
me that there's a kernelpatch reducing that pipe related latency by a
factor of 10. Another bonus of using threads and pipes is that you
can easily support feedback within a network. Otherwise you would have
to write a quite complicated scheduler for feedback and parallel
processing. Ok, I admit that the glame approach is probably to generic
for "real" world processing and therefore in some cases not as performant.
But anyway, glame was designed for postprocessing and building "realtime"
networks is a nice side effect, even if they may not reach hard realtime
performance. But I'm quite optimistic that we can tune our code in the
long run. As I said before I've got more problems with my sound hardware
than with context switches at the moment (in terms of low latency).
The ymfpci&maestro drivers give me a real bad time.. Maybe I should
get the upcoming Hammerfall card, if you write a driver for it ;)
Cheers, Alex
--It were not best that we should all think alike; it is difference of opinion that makes horse-races. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
This archive was generated by hypermail 2b28 : Mon May 14 2001 - 02:12:11 EEST