> (...)
> 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
-
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/