Linux-kernel mailing list archive 2000-26,: Re: a joint letter on low latency and Linux

# Re: a joint letter on low latency and Linux

Paul Barton-Davis (pbd@Op.Net)
Fri, 30 Jun 2000 10:46:27 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dunlap, Randy: "RE: USB SanDisk SmartMedia - some results."
- Previous message: yodaiken@fsmlabs.com: "Re: a joint letter on low latency and Linux"
- Maybe in reply to: Paul Barton-Davis: "a joint letter on low latency and Linux"
- Next in thread: yodaiken@fsmlabs.com: "Re: a joint letter on low latency and Linux"
- Reply: yodaiken@fsmlabs.com: "Re: a joint letter on low latency and Linux"

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Dunlap, Randy: "RE: USB SanDisk SmartMedia - some results."
- Previous message: yodaiken@fsmlabs.com: "Re: a joint letter on low latency and Linux"
- Maybe in reply to: Paul Barton-Davis: "a joint letter on low latency and Linux"
- Next in thread: yodaiken@fsmlabs.com: "Re: a joint letter on low latency and Linux"
- Reply: yodaiken@fsmlabs.com: "Re: a joint letter on low latency and Linux"