Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

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

Sure, I was just being pedantic about Larry's example.

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

No good. 

This assumes it takes zero time for the linux process to do its
thing. If you were running a faster clock, and could tell "ahead of
time" that the linux process hadn't run yet, you could recover. but
otherwise, the RTLinux process is going to run because an audio
interface interrupted, and by that time, it will be too late to try to
generate the data that should have been computed already. Recall: the
RTLinux consumer's job is to move data from shared mem down to the
audio interface. If the data is not ready when it runs, its already
too late.

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

the requirement that we have is primarily that interrupts are not
disabled for more than some fraction of the audio interface interrupt
interval. if this is guaranteed, then we know that we'll service the
audio interface interrupt within a suitable short time after it
occured, at which time, we will discover a SCHED_FIFO task is ready to
run again, and we'll run it.

to put this another way: we have our own clock source, and we use
SCHED_FIFO to override the default scheduler. all that matters is that
our clock source is not disabled. if its not, then we will regularly,
and on-schedule, be awarded the processor. if the SCHED_FIFO thread is
using mlocked memory and does not block on anything other than io
to/from the audio interface, then it will always run on time, and in
time (assuming its not trying to do too much work).

i hope i got this right, because this is an important re-casting of
what is important for these kinds of apps. its not about latency
per-se, although that certainly matters. its about making sure that
the audio interface interrupts result in our task getting back onto
the processor promptly.

--p