Re: [linux-audio-dev] API design again [MORE code]

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] API design again [MORE code]
From: David Olofson (audiality_AT_swipnet.se)
Date: ti loka   12 1999 - 01:06:18 EDT


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.

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

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

> (Much time stamping will be done in kernel drivers anyway, or?)

That's the way I want it, anyway... Precision timestamping and
simulating missing hardware features is *not* a user space job.
However, as current drivers don't timestamp, that'll have to do for
now.

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST