Subject: Re: [linux-audio-dev] user lowlatency kernel experience
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Jun 14 2001 - 09:05:34 EEST
>> the long answer is that the apps have to be written to cooperate, and
>> that since they are not written to cooperate, they need to be run by a
>> scheduler that understands what to do. this has a lot to do with the
>> LAAGA discussion now under way on this list.
>
>The short answer to the original question is "it's easy, but not with a
>fixed-priority scheduler".
>
>The long answer is that during the past decade or so there has been a
>ton of work on supporting concurrent, independently written real-time
>applications in real-time and general-purpose operating systems.
i don't believe that any of those published are used in audio systems.
for audio (and video too, i would imagine) the problem with
conventional RT schedulers is that they are based on wall clock time,
and we need schedulers based on audio time. if the relationship
between the two was linear, this would be simple to accomplish, but
its neither linear nor consistent. estimating how many msecs are
needed to generate N frames of audio is far from trivial. and in fact,
its really a rather pointless computation: if you can do it within the
"right" amount of time, then we don't care how long it takes; if you
can't then we also don't care how long it takes, because the system is
broken.
the situation is, IMHO, much like the one that gave rise to scheduler
activations (which i know john knows as much if not more about that i
do): the kernel has the mechanism but user space has the information.
thats why i believe that (95% of) the correct answer is for the kernel
to not try to be smart about processor allocation (just as with SA's,
where the kernel doesn't try to figure out which of a process' threads
to run), but to simply get back into user space where the right thing
can happen.
hence, a design like (my version) of LAAGA: a central SCHED_FIFO
thread ("the engine") driven by a h/w interrupt which causes other SCHED_FIFO
processes to run in order. the engine understands the order in which
to run the other processes, just like the user space SA scheduler
knows which threads to run.
of course, this doesn't solve the case of pathological clients which
hog the CPU; this is easily solved by making the engine slightly
higher priority than the others, and using a watchdog timer to wake it
up if it gets stuck waiting for a client. it doesn't guarantee glitch
free audio, but it does ensure that the system runs OK.
--p
This archive was generated by hypermail 2b28 : Thu Jun 14 2001 - 10:55:07 EEST