<p dir="ltr">It should also be said that the naiive algorithms have quadratic runtime complexity whereas the best ones have much better complexity (I believe n log n), so longer reverb tails that can be done with the optimized algorithm are simply not possible with the naiive approach, no matter how much hardware you throw at it - so that might be another reason to spend the time.</p>
<br><div class="gmail_quote"><div dir="ltr">On Mon, 13 Feb 2017 14:40 cheater00 cheater00, <<a href="mailto:cheater00@gmail.com">cheater00@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr" class="gmail_msg">The simplest FFT and convolution algorithms are easy to understand in just hours, the really complex algorithm could take weeks to implement, so if you're just doing this for yourself the break even point is: will you otherwise earn $200 - the difference between a dev board with the cheapest DSPs and most powerful ones - in those several weeks? If not, you might want to look into, uh, flipping burgers or pizza delivery as a career move. If you are doing this for production, or for other people to build themselves, you want something relatively inexpensive, though. The dev time might be warranted if you do not mind spending it as a learning experience.</p>
<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, 13 Feb 2017 10:38 Thomas Strathmann, <<a href="mailto:thomas@pdp7.org" class="gmail_msg" target="_blank">thomas@pdp7.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/02/17 22:39, <a href="mailto:rsdio@audiobanshee.com" class="gmail_msg" target="_blank">rsdio@audiobanshee.com</a> wrote:<br class="gmail_msg">
> So, when combining FIR and FFT processing for convolution, you'll<br class="gmail_msg">
> need MAC, bit-reversed addressing, automatically-wrapped buffer<br class="gmail_msg">
> pointers, and possibly other special instructions for maximum<br class="gmail_msg">
> efficiency at a given instruction clock rate. Hopefully the DSP you<br class="gmail_msg">
> choose will have example code in optimized assembly for a partitioned<br class="gmail_msg">
> convolution, and you won't have to piece all of this together<br class="gmail_msg">
> yourself. Yes, you could do it all in Standard C on a general purpose<br class="gmail_msg">
> ARM or XMOS, but you'll need a higher clock rate and more code to do<br class="gmail_msg">
> the same amount of work.<br class="gmail_msg">
<br class="gmail_msg">
I'm wondering: How precious would development time hav to be to warrant<br class="gmail_msg">
going with a DSP and optimized assembly code instead of taking the more<br class="gmail_msg">
blunt approach with a fast CPU and some plain C code? From following<br class="gmail_msg">
this discussion I get the impression that the answer to that question is<br class="gmail_msg">
"Very" but is that true?<br class="gmail_msg">
<br class="gmail_msg">
        Thomas<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Synth-diy mailing list<br class="gmail_msg">
<a href="mailto:Synth-diy@synth-diy.org" class="gmail_msg" target="_blank">Synth-diy@synth-diy.org</a><br class="gmail_msg">
<a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" class="gmail_msg" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br class="gmail_msg">
</blockquote></div></blockquote></div>