Re: a joint letter on low latency and Linux

On Thu, Jun 29, 2000 at 09:19:56PM -0400, Paul Barton-Davis wrote:
> >OK, now we are getting somewhere.  So I have a kernel level source, user
> >level processing, and a kernel level sink, right?  And the problem is that
> >we can have long delays which mess that up.  Here is how you handle that
> >with RTLinux:
> >
> >There are three processes:
> >
> >    RTLinux producer
> >	for (;;) {
> >		sample();
> >		put_data_in_shared_mem();
> >		up(producer_sema);
> >	}
> >
> >
> >    Linux processor
> >
> >	for ( ;; ) {
> >	    down(producer_sema);
> >	    get_data_from_shared_mem();
> >	    process();
> >	    put_processed_data_in_shared_mem();
> >	    up(consumer_sema);
> >	}
> >
> >    RTLinux consumer
> >	for ( ;; ) {
> >	    down(consumer_sema);
> >	    move_shared_mem_to_device();
> >    	}
> >
> >I think that 99,000 out of the 100,000 lines of code still lives in the
> >Linux process just like it always did.  The only difference is that the
> >RT processes get scheduled when they need to get scheduled - the Linux
> >kernel and all of it's processes get preempted any time a RT process
> >wants to run.
> 
> OK. And what happens when "linux processor" stalls for 65ms because of
> linux ? The RTLinux consumer doesn't have the data it needs (actually,
> it doesn't run, if the semaphores work as expected), and we get an
> audio dropout.

A) You don't use semaphores, you use well known methods that are lock
   free. 

B) If the RT consumer finds low data, it can take an emergency action to
   force Linux to run the "linux processor" next. If the clock is
   ticking at 10 milliseconds, we will be fine -- assuming the app 
   works on a stream.

BTW: I'm agnostic about how audio applications, in general, should
    be written but I do have two observations:
     1. Hard realtime deadlines are hard realtime deadlines. To say that
        you "only" need to run ever 5miliseconds is to say you need 
        a hard realtime system.  You don't need realtime only when 
        "average" case or some other statistical measures is good enough.

     2. Even when you just need QOS (quality of service) statistical
        timing, you need some underlying hard RT to enforce QOS when
        times get out of line: if missing 5 frames a minute is ok, but 6
        is not, you need to enforce timing when 4 or 5 frames have dropped
        in the last 50 seconds.

    

> 
> Thats why, as David Lang patiently explained, if *any* of the
> processing path between the audio interface capture side and its
> playback side is subject to delays, you've lost. Ergo, the processing
> part has to be in RTLinux as well. Presto, we're back to something
> which, despite the elegant design of RTLinux, from a programming and
> debugging point of view is just like the terrible stuff thats done by
> putting soft synths into device drivers in windows to get close to
> reasonable performance.
> 
> --p
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
---------------------------------------------------------
Victor Yodaiken 
FSMLabs:  www.fsmlabs.com  www.rtlinux.com
FSMLabs is a servicemark and a service of 
VJY Associates L.L.C, New Mexico.