[sdiy] Hardware convolution box?

[Scott Gravenhorst]

Thomas Strathmann <thomas at pdp7.org> wrote:
>On 12/02/17 22:39, rsdio at audiobanshee.com wrote:
>> So, when combining FIR and FFT processing for convolution, you'll
>> need MAC, bit-reversed addressing, automatically-wrapped buffer
>> pointers, and possibly other special instructions for maximum
>> efficiency at a given instruction clock rate. Hopefully the DSP you
>> choose will have example code in optimized assembly for a partitioned
>> convolution, and you won't have to piece all of this together
>> yourself. Yes, you could do it all in Standard C on a general purpose
>> ARM or XMOS, but you'll need a higher clock rate and more code to do
>> the same amount of work.
>
>I'm wondering: How precious would development time hav to be to warrant 
>going with a DSP and optimized assembly code instead of taking the more 
>blunt approach with a fast CPU and some plain C code? From following 
>this discussion I get the impression that the answer to that question is 
>"Very" but is that true?

My answer would be "very" based on my experience.  I've been developing MIDI
synthesizers on a Raspberry Pi 3 using C (with NEON enabled).  The synths all use
single precision float (because it's native to NEON) and I've attained from 16 to 64
voices of polyphony and includes a reverb effect.  Actual voice count depends on the
complexity of the synth's internals.  I can't say how this translates to convolution
because I've not tried it yet, but I have to say that for such an inexpensive board,
it is really quite powerful.  I actually didn't expect the performance level I'm seeing.

-- ScottG
________________________________________________________________________
-- Scott Gravenhorst
-- http://scott.joviansynth.com/
-- When the going gets tough, the tough use the command line.
-- Matt 21:22