Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

>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.

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