Subject: Re: [linux-audio-dev] API design again [MORE code]
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: ti loka 12 1999 - 15:40:11 EDT
David Olofson wrote:
>
> On Tue, 12 Oct 1999, Roger Larsson wrote:
> > 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.
>
> Exactly. Add one rule for real time systems:
> Higher scheduling rate should have higher priority.
>
> Without that one, the whole point with sceduling the higher rate task
> for every external event is lost if the lower rate task delays the
> higher rate task for a few wakes every now and then.
>
Well, we are not designing a hard real time system here, are we?
What would be more frustrating to the user?
Something happens that make the sound engine miss a deadline:
a) It closes down. All sound disappears until it is restarted.
b) It lose some data. Sound is disturbed for a short time.
Maybe it should be a configurable option... During testing you
probably want it to stop, but not close.
> > 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.
>
> System overload ==> automatic engine shutdown. (To avoid hanging the
> system, as the engine might well be running SCHED_FIFO.)
>
> If the engine fails to handle incoming data because of the sensor
> thread CPU load, it will also fail to do it's processing before the
> deadline. That's a very severe error condition in a real time system,
> and it makes no sense trying to handle it nicely. If a deadline is
> missed, all is lost anyway...
>
If you schedules all sensor threads uncoordinated I assume you could
get into a situation where all sensors want to run at once.
(but it should not make you run out of RAM...)
Anyway I would like a unthreaded event dispatcher... I have some
ideas...
> > With a fast engine, the jitter in time stamps might be worth it...
>
> No. Almost by *definition*, the engine should work correctly until
> the CPU is overloaded. That is, the engine thread may well be working
> 90% of the cycle time slice.
>
Ok, ok, I give up...
--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:59 EST