Subject: Re: [linux-audio-dev] API design again [MORE code]
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: ma loka 11 1999 - 19:32:57 EDT
David Olofson wrote:
>
> On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> > [ ... 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 ... )
>
> Scary... *hehe*
>
> > 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.
>
> Ok, that's exactly the sleep point I had in mind...
>
> > "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.
>
> Yep. However, there's one thing to keep in mind here (at least with
> the kernel MCS implementation I have in mind); it's perfectly
> possible that the *engine* never calls an I/O plug-in, and therefore
> never sleeps that way. Instead, it'll have to sleep on the MCS
> connection it's supposed to be sync'ed with, after each finished
> cycle. (Like Benno's client/server interface.)
>
> > 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.
>
> Above, as they have to be able to preempt the engine to get correct
> timestamps.
>
Thumb rule for priority:
The shorter run the higher priority.
The longer run the lower priority.
Then the short run can interfere with the long but not the opposite.
But there are exceptions:
To avoid filling up processor queues it might be better to
run producer threads with lower prio. - consumer threads will
then be able to empty their input queues before new ones are
created.
This is not a good solution if you can not combine inputs, or
ignore some.
Example:
suppose that engine threads have lower prio. than sensor threads.
and that each sensor tread is "connected" (1-1) to a plugin.
then data may build up, and overflow, on the input to the engine
by using more sensor threads than expected.
With a fast engine, the jitter in time stamps might be worth it...
(Much time stamping will be done in kernel drivers anyway, or?)
/RogerL
--The Internet interprets Windows as damage, and routes around it.
Roger Larsson Skellefteċ Sweden
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST