Re: real-time threaded IO with low latency (audio)

Ove Ewerlid (Ove.Ewerlid@syscon.uu.se)
Sun, 25 Jul 1999 13:04:34 +0200

David Olofson wrote:
> Steve Underwood wrote:
> > Not possible on a dedicated DSP? Rubbish. A large number of DSP apps do just this.
> > You clock the DSP from the same source as the converters. At the start of
> > execution you sync up to the flow from the data source. After that you use a
> > processing loop padded so its execution time is precisely related to the sample
> > interval of the data flowing through. DSP chips usually have deterministic
> > processing times - no vagueness with caches, and so on. If the processor is fast
> > enough to leave a few spare processing cycles, its a good idea to do a sync check
> > each time round the main loop. If not, just live with it!
>
> Anyway, we're off topic here again... We can't tune Linux to THAT level,
> after all! ;-)

Have to disagree, if linux can lock a processor to "anything" then linux
has done what
it can wrt tuning and the limits are in the hardware. I have very good
experiences with DSP
algorithms on locked Pentiums CPU's (L1 cache). In typical hard real
time audio signal
processing you usually have tight loops that dominates the time
complexity.
The worst case _conditionals_ are usually not a problem.

This assumes that you can split the algorithms into one hard category
and one soft or for
that matter one fast and one slow. Here is a real word example -
inversion of speaker
audio characteristics and cancellation of echo effects in the room where
you listen to
the sound. In short you need a number of rather long FIR filters
operating at 44.1 kHz
and a more advanced high level adaption algorithm that computes new FIR
filter coefficients
a couple of time per second (based on feedback from the room).
FIR filters written in assembler and high level algorithm written in
C/C++ or for that matter
directly in some interpreted tool for matrix computations (such as
matlab).

Linux can deal with this scenario just fine as long as it has CPU
locking.
One processor deals with the FIR filter and one processor deals with the
rest.
Using shared memory via MMAP allows very optimal interprocess
communication.

When you work with this type of algorithms you do not want the OS to be
in the way.
You want the OS to pave the wave to the hardware (with mmap) and give
you a nice
development environment.

Ofcourse you can find examples where the PC _hardware_ is not good
enough and you
simply have to resort to DSP and the high costs you usually find there
(money/time).
If the PC-hardware is not good enough there is nothing linux can do
about it.

For comparisons, a vanilla PII@400 MHz, executes 100 miljon FIR
operations per second.
This is using 64 bits floating point. You usually end up using 32 bit
floats to get
as much as possible into the L1 cache.
(That makes 200 miljon FLOPS)

I think that many audio freaks want to work directly ontop of the bare
hardware
and this is something linux offers today with very little modifications.

Ove

-- 
Ove Ewerlid
Ove.Ewerlid@syscon.uu.se or Ove.Ewerlid@signal.uu.se
Phone: +46 70 666 23 63, Fax: +46 18 503 611, +46 18 555 096


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/