Messages in this thread | | | Date | Wed, 28 Jul 1999 23:48:53 +0200 (MET DST) | From | Bjorn Wesen <> | Subject | Re: porting linux to DSP |
| |
On Wed, 28 Jul 1999, Dan Hollis wrote: > In 1989 a DSP was probably a good idea. > > In 1999 it is basically pointless.
right.. but to make this on-topic again, i'd say that this ties nicely in with the thread about RT linux.
what is the argument for putting a dsp in a pc (for audio) ? it's not that the main cpu can't do it, it's because you want to guarantee that certain tasks will run uninterrupted, and a dedicated chip can do that.
if you could _allocate_ a certain amount of instructions per second on the normal CPU, it would in essence be like a separate dedicated chip. on a p2/400, you could dedicate 10% of the cycles and it would be like a normal DSP chip. i guess this is what the audiality guys and other HD recording people are talking about in the realtime linux threads.
because, when designing dsp algorithms, you often count in cycles per sample etc. like, "i have 250 cycle cpu power per sample" (dividing the mips by the sampling frequency). you can then allocate it like 5 cycles for a small filter etc. if i could be guaranteed that linux would give me a certain amount of time unconditionally per second, and with a latency that lies within the timewindows set by the buffers involved, problems would be solved no ?
would compromises work, like you do the processing in a timer or soundcard interrupt driven fashion instead, while letting disk i/o proceed buffered through normally scheduled tasks ? or is linux filesystem/buffer system so varying in speed that you can't use as small buffers as you need ?
-bjorn
- 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/
| |