Matthias Meyer wrote:
Hey Theo,
it is nice to see interest in FPGAs here. I have worked with FPGAs for
some years now and always wanted to use it for audio processing. Because
the FFT is indeed really fast I thought about using it for real-time
pitch detection. The Zynq platform is ideal because you can use Linux
and the FPGA. I implemented some basic (multi)pitch detection algorithms
on it using an accelerated FFT on the FPGA.
...
I've done a number of things with programmable logic in connection with audio and
synthesis, let me mention here the synthesizers that Scott Gravenhorst made for the
Spartan 3E board which are cool.
Compared with fast DSPs, the advantage of the FPGA fabric and available IP blocks is that
the instruction set of the DSP is limited, and the instructions and data must all the time
come one instruction at the time from a few special registers or the main memory plus
caches, there's not very much parallel data for the heavy arithmetic unit computing
elements. So in this case, there's a smart, hundreds of mega hertz internal clock
frequency set of basic DPS blocks with short communication time and over a lot of fast
FPGA internal wires connected with special (small) FPGA internal memories, and a control
logic created by design software such that the whole operation is very quick on the, what
is it, Virtex-6 or so chip fabric.
Before you'd have the whole thing working though, it's an amount of engineering that I
didn't completely look into, in order to do the preferably stereo processing on a real
time 96kHz/24bits audio stream, which would fit in the smallest Zynq (which I have). I can
communicate over the AXI bus to do DSP connected with the ARM cores, but getting that
communication working reliably for my type of processing may well be some work, and
feeding and using the output of the FFT block I looked at may be somewhat hard as well, I
can't tell up front.
It would allow at least at 96kHz (I'd prefer at 192kHz, because that's in the line of what
I use on fast PCs) to do a *WHOLE* FFT of 1024 points in this case, *within 1 sample
time*! That's quite fun. That makes it possible without additional hassle to impose a
weighing function and get a completely averaged iFFT (didn't look into that) perfectly per
sample. Maybe that can be done more efficiently when decomposing the FFT computations, but
that would make a good audio processing mastering effect, even more neatly averaged than
the Linux "Jamin" (which I think averages a number of FFT->Filter-IFFT output datapoints,
but not a completely sliding window, IIRC).
Very good for mid-frequency power control/measurement.
Anyhow, of course there are more uses, like measuring, extrapolating different audio frame
processing outcomes, etc.
T.V.
_______________________________________________
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp
