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/