Re: real-time threaded IO with low latency (audio)
David Olofson (audiality@swipnet.se)
Sun, 25 Jul 1999 08:36:01 +0200
Steve Underwood wrote:
>
> David Olofson wrote:
>
> > (...)
> > However, that's not good enough for high end audio processing and other
> > tasks that require BOTH deterministic timing AND lots of CPU time. The
> > longer time a RT process needs to do it's work, the less scheduling
> > jitter can be tolerated.
> >
> > For the (hypotetical - not possible even on a dedicate DSP) extreme case
> >
> > buffer_play_time == processing_time == buffering_time
> >
> > no jitter at all is acceptable.
>
> Not possible on a dedicated DSP? Rubbish. A large number of DSP apps do just this.
> You clock the DSP from the same source as the converters. At the start of
> execution you sync up to the flow from the data source. After that you use a
> processing loop padded so its execution time is precisely related to the sample
> interval of the data flowing through. DSP chips usually have deterministic
> processing times - no vagueness with caches, and so on. If the processor is fast
> enough to leave a few spare processing cycles, its a good idea to do a sync check
> each time round the main loop. If not, just live with it!
>
> Steve
Well, you're right there, off course. I didn't really have THAT extreme
forms of dedicated systems in mind. However, to be very picky here, the
word "padded" breaks your argument. Take another look at this...
> > buffer_play_time == processing_time == buffering_time
You're right about the rest, as jitter is not at all a problem in a
padded loop running on a DSP that's synchronized to the sample clock.
But as soon as you need some conditional code, you're in it deep.
Anyway, we're off topic here again... We can't tune Linux to THAT level,
after all! ;-)
//David
-
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/