Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

>> >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.
>
>I'm adding a feature to our RTLinux consumer. It collects a frame
>and dumps it, then it looks at the queue -- if the queue is at a low
>water mark, the RT consumer reaches down into Linux, sets need_resched and 

there is no queue. this is real time FX processing or synthesis,
remember ? 

>> 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.
>
>I don't get the distinction. Worst case latency between the audio
>interface and the running of the app seems to be your concern.

right, and what i was forgetting was that returning from an interrupt
in kernel mode does not cause a reschedule. duh. kind of basic, but
the central problem in this story. 

ok, so now i see where the UP-threaded stuff kicks in.

--p