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 - 21:20:12 EDT


On Tue, 12 Oct 1999, Roger Larsson wrote:
> Well, we are not designing a hard real time system here, are we?

On the contrary, we are.

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

Both are fatal and must never happen. But b) is of course a nicer way
of taking care of the error condition, if the user fails to realize
that it's impossible to use 98% of the CPU time reliably...

> Maybe it should be a configurable option... During testing you
> probably want it to stop, but not close.

Well, closing it down is of course a bit brutal. After all, this is
not the lab intstrument I'm programming at work, where a controller
failure can wreck the air bearing that carries the motor and
measurument system. Cost: $1000 + work.

[...]
> 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...)

Yes. But real time is real time. The only way to stay out of trouble
is to make sure all RT threads do their job correctly. Of course, you
can have various watchdog systems, but getting them to work, and do
anything useful about a critical condition is usually rather
complicated. Easier to makie sure the sensor threads don't freak out
in the first place.

> Anyway I would like a unthreaded event dispatcher... I have some
> ideas...

Only possible with timestamping drivers, or devices that inherently
deliver timing info through the data.

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

Well, time is a mean beast; not much to do about that... :-)

//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:59 EST