Re: a joint letter on low latency and Linux

[Benno Senoner]

On Fri, 30 Jun 2000, Larry McVoy 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.

No, the MIDI soft-synth can not live within the Linux processor thread,
due the fact that every 2-3msecs it has to spit out an audio fragment
or you risk to miss the deadline.
As stated in my other mails the MIDI synth is a complex application.
(a very demanding one in terms of ressources)

> 
> Think about this.  You already have a mechanism that gives you exactly
> what you need.  And it is _way_ better than any of the proposed hacks.
> The only complaint that is valid is that it is "different".  Yup, that's
> true, the wheel was different too.  Such is life.  You have to give a 
> little to get a lot, that's a better tradeoff than you normally get.

Yes it's a complex situation.
For example if we were talking about QNX (and RTOS) where
all audio/drivers work as RT kernel processes then the choice
would be easy: use the kernel programming model
(very similar to RTLinux)

But Linux, being an Unix clone uses the the device concept
where userspace apps talk to them using syscalls
And here making decisions is much more frustrating, because
you already have a fully working enviroment, with the exception
that the worst case latencies are a bit high.

And being forced to use a radical different API / system to only
achieve a bit better latencies means a non-negligible amount of
added work/problems for all parties involved.

Benno.