[sdiy] Hardware convolution box?

[cheater00 cheater00]

Brian, $50 is a steal. I've had a look at Digikey.

This TI board is £24. It has ~150 KB on-chip RAM, but it has an
integrated SDRAM interface.
http://www.digikey.co.uk/product-detail/en/texas-instruments/LAUNCHXL-F28377S/296-42484-ND/5404239


This TI board is £40. It has ~384 KB on-chip RAM and an integrated
SRAM interface and SD card support. 200 MMACS.
http://www.digikey.co.uk/product-detail/en/texas-instruments/TMDX5505EZDSP/296-24965-ND/2127652

This AD board is £60. It has 1MB on-chip RAM and USB host mode, no
idea about ram interface or SD card. 800 MMACS.
http://www.digikey.co.uk/product-detail/en/analog-devices-inc/ADZS-BF706-EZMINI/ADZS-BF706-EZMINI-ND/5408943

This last one sports 800 MMACS. Is this enough processing power for
the 5-second convolution I mentioned above? It seemed to me like that
would need 4608 MMACs. Maybe 2304 if we take pairs of 16 bit samples
and treat them as 32 bit values. Are my numbers correct? Are there
optimizations that can be done to lower this number, while still
having zero latency? I understand FFT domain convolution introduces
latency, which is not wanted in hardware. "Naive" MAC based
convolution doesn't seem too far out of reach.

This TI board is £156. It has 256 KB on-chip RAM and support for DDR2
SDRAM. No mention of MMACs but they say 3648 MIPS and I assume a
pipelined MAC costs one instruction, would that be correct?
http://www.digikey.co.uk/product-detail/en/texas-instruments/TMDSLCDK6748/TMDSLCDK6748-ND/5213032


The more expensive boards don't seem to have more powerful DSP chips.
And those chips don't really get much more powerful either. However,
convolution is easily parallelised. So, worst case scenario, if you
wanted really long impulse responses you'd have to use a few chips.
However, even the really good 800 MMACS Blackfin ones are £15 unit
price, so that's not so bad...

So, tell me, why hasn't anyone made this yet?

On Tue, Feb 7, 2017 at 4:38 AM,  <rsdio at audiobanshee.com> wrote:
> Hi guy,
>
> A DSP chip is going to be hundreds of times more efficient than a generic ARM processor (even the ones with a MAC instruction). The reason DSP beats a generic CPU is that the instructions are optimized for signal processing, and often a single-cycle instruction can handle several different operations in parallel that might be needed. A generic CPU will need to execute several instructions to implement the same calculations.
>
> Good options are the Texas Instruments TMS320 family, the Analog Devices SHARC family, and the Motorola/freescale/NXP 56000 DSP family. It's a steep learning curve, though, because the best code is often written in assembly to take advantage of the unique instructions of each family of DSP.
>
> You'll need to select a chip that can address a large amount of memory, because convolution requires more memory than the average DSP operation. Not many chips will have a lot of on-board memory, so be sure to look for chips that have an external memory bus that can address the samples in your impulse response.
>
> Texas Instruments has boards with audio inputs and outputs for $50 and up that you could get started on. But you'll have to check the memory provided and the clock rate to be sure.
>
> Brian Willoughby
> Sound Consulting
>
>
> On Feb 6, 2017, at 6:08 PM, cheater00 cheater00 <cheater00 at gmail.com> wrote:
>> does anyone make an inexpensive hardware convolution box with stereo
>> in/out? I need a couple secs of response at 48 kHz.
>>
>> Has anyone considered using one of those inexpensive arm based
>> mini-pcs for this purpose?
>>
>> What sort of processing power does one need for convolution? I'm not
>> sure how to calculate this. My calculations were: to apply a
>> two-second IR at 48 kHz onto incoming 48 kHz signal, you need, per
>> channel, 2*48000 multiplications for each sample being put out. You do
>> this 48000 times per second. So in the end for each channel you need
>> 2*48000*48000 multiplications per second, or 4608 MIPS per channel.
>> Then you need to do the additions as well, and then account for the
>> other channel. That's a whole lot. Am I missing something?
>>