On Fri, Jun 30, 2000 at 10:46:27AM -0400, Paul Barton-Davis wrote:
> >> >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'm confused. I thought that buffering was possible.
Get data -> send it to processor -> output result
couple of seconds of
buffer here.
>
> >> 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
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
