Subject: Re: [linux-audio-dev] API design again [MORE code]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su loka 10 1999 - 12:38:59 EDT
[ ... sleeping ... ]
>So where do you get the CPU time for other tasks, if the engine never
>sleeps...? Or am I missing what you're actually saying here?
(for a moment there, i thought i had fallen into my "i have a dual CPU
box and so does everyone else" trap. but fortunately, no ... )
the engine sleeps whenever it calls a plugin that calls
read/write. how long it sleeps depends on the i-node it reads/writes.
if it never calls read/write, it will never sleep.
"nothing is calling read/write" is actually a pathological situation,
but relatively easily dealt with. quasimodo and hdr both have to do
this. for quasimodo, a plugin must be able to tell us if it does
input. for hdr, if there are no inputs active then we stall the
engine. we focus on input because output is handled in these programs
by the "engine" itself. in MCS, this may not be true, so the
work_to_do() test has to include active ins OR active outs.
sensor threads should run with SCHED_FIFO, but its not clear to me if
they should have a priority above or below or equal to that of the
engine thread.
>Anyway... FIFO. Any other behavior would be erroneous and fatal in
>this case. If your events are late for the cycle, you're missing a
>deadline, which is a Very Bad Thing(tm) in a real time system.
>> >Actually, there's one more level; the transfer of the finished list
>> >of events (for the cycle) to the destination port.
>>
>> this can't happen without locking. we don't want to do this.
>
>A FIFO doesn't need locking in the single reader - single writer
>case, and it also allows queueing of multiple event buffers. That
>means we get cycle period matching almost for free. The engine only
>needs to grab the buffers one by one and do the compulsory time stamp
>conversion.
time stamp conversion ? the sensor thread should have timestamped the
events with the same timebase as the engine. hence:
ev->timestamp = engine->timestamp();
>> sorry, this won't work. once again, a sensor thread is not going to
>> wait for a command to "finish the cycle". its working asynchronously
>> with respect to the engine.
>
>So, your "cycle time" will have to be based on the only wake up
>source you have; the device you're sensing. However, that does not
>mean that you have to pass one event at a time. Just send'em all of
>before you go back to sleep.
well, yes, of course. but the point here is that this sending will
happen (potentially) in the middle of the engine's control
cycle, not at a point defined by the engine.
the overall point here is to think of the engine as collecting events
from the subscribable ports, not as the sensor threads delivering them
anywhere. then all this "shadow port" stuff goes away. the only key
thing, as i said before, is to ensure that we have reliable lock-free
event queues for the ports.
[ ... handling non-shared memory stuff ... ]
>Ok, just set up a communication thread with a sensible cycle rate, in
>case event rate >> fixed latency. ("Fixed latency" being the jitter
>elimination delay that makes time stamps useful.) What I mean is that
>it's insane to send events 20 times during a single fixed latency
>period.
not really, if you forget about this idea of "sending" as an active
thing. you're just putting events on a queue. somebody else will take
them off when they're ready.
>No, that's not the idea. I only want to clean up the API, and make it
>posible to change the implementation without breaking the API.
>
>API != implementation.
yep. and i think we agree that using a communication thread will
satisfy this, so we can exclude all considerations of non-shared
memory from our discussion :)
>> aha! you admit it: "runs whenever it wants". this is why the
>> "finish_cycle" operation idea won't work.
>
>finish_cycle() *can* be called whenever you want. (Plug-ins don't
>need it, as returning from process() has the same meaning.) It's just
>that *recommending* that it's not called more frequently than
>necessary will make optimization of the implementation a bit easier.
you write as if the engine calls finish_cycle(), and this is what i
meant would not work. sure, a sensor thread can do this whenever it
likes, but then it doesn't need a special name - its just another
thing the sensor thread does on its own.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST