Not being too serious there, I didn't mention that I had only single CPU
systems in mind. I wouldn't call a single CPU locked to a single process
one running Linux...
> 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.
No, not on a system that's _synchronized_ as opposed to a DSP loop
padded with NOPs...
> 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.
I'd say that's more "working around Linux" than "Linux dealing with it",
but so what; it works! :-)
> One processor deals with the FIR filter and one processor deals with the
> rest.
> Using shared memory via MMAP allows very optimal interprocess
> communication.
Much like a DSP card, but with a lot faster "card<->host" communication,
a niced development environment, lower price, more power and no weird
hardware that's hard to get at. :-)
> 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.
Yep, but if I can do with the jitter caused by cache misses and the
latency lower limit implied by context switching, I think using, say 80%
of BOTH CPUs is pretty interesting too. And that's good enough for most
kinds of music/audio processing, which is what I'm most interested in.
However, locking one CPU for ultra low latency processing, and using 50%
of the other one for RTL at higher latency could be pretty
interesting...
> 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)
That should do for a couple of flangers... ;-)
> 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.
Agree, and I have to admit that this discussion made me realize that my
old ideas of single sample input->output latency may not be completely
impossible, at least not on SMP systems. By compiling plug-ins
"statements" into a tight loop executed on the locked CPU when the user
changes the signal routing, this kind of latency may even be possible to
use in a quite transparent way.
My hihest priority is end users being able to get their audio
recording/editing/processing work done as reliably on a PC as on
dedicated hardware, and less than 1 ms of latency isn't really
necessary. But why stop at that? What's pointless overkill today is an
expected feature tomorrow...
> 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
//David
-
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/