Well, actually my answer wasn't really focused on flanging... Because of
the delay issue, I agree that flanging is a bad example. (Not MY idea!
;-)
What about simulating an RC filter? can be done one sample at a time,
using a single variable (C) per channel... In that case, the
input->output delay depends only on the hardware and the scheduling.
THAT's low latency processing! :-) (If it's practically useful is
another matter...)
> Only if flanging is to be done directly from a microphone to a
> loadspeaker
> does the problem become interresting iff you need to minimize the delay
> the signal spends in the computer.
That's the kind of processing I'm interested in. And the delay should be
as low as possible (within reasonable limits), and still, there must
never be a single drop-out.
> Here you must work very close to the
> hardware,
> eg, mmap and I do not think RTlinux helps here.
Why not? For example, I can setup a periodic task at, say 8 kHz,
watching the DMA buffers or whatever. The big advantage over user space
is that the task will preempt EVERYTHING, including all Linux
interrupts. There will be no drop-outs.
> I think flanging is a bad example in this discussion as flanging is not
> very CPU-intensive. Try running a 1024 point FIR filter instead :-)
Agree. And again, that RTL task will just take as much CPU time as it
needs. (Be careful; control brings responsibility... A watchdog task is
strongly recommended!)
//David
> 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/