Messages in this thread | | | Date | Sun, 25 Jul 1999 13:04:34 +0200 | From | Ove Ewerlid <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
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/
| |