[sdiy] audio microprocessors and C++

[Eric Brombaugh]

It's possible to do hardware implementations of synthesis using C/C++.  
The main problem that you'll run into however is that prototyping on  
PC hardware using Win/Mac/Linux doesn't give you a good idea of the  
limitations you'll run into with DIY hardware. Basically the issue is  
that modern PC CPUs are _extremely_ powerful - you can do some fairly  
sloppy programming, run a bunch of other stuff in the background,  
watch a DVD, etc and your audio algorithm will still meet the real- 
time deadlines. On DIY microprocessors this isn't the case though, and  
you'll need to guard those cycles jealously. And you probably won't be  
able to use floating point.

With that understood though, there are a few C programmable MCUs that  
are DIY friendly: various flavors of ARM processors and Microchip  
dsPICs to name a few. Atmel makes the SAM7 series of ARM processors  
that have I2S serial interfaces that can drive audio DACs directly.  
Analog Devices ARM7-based processors have ADCs and DACs on-chip. All  
of these can be programmed with free (Gnu-based) development tools in  
either C or C++, or there are some excellent development systems  
available for reasonable prices.

Alternatively, the Freescale SoundBite DSP system that was being  
discussed here a few weeks ago is also a path to audio synthesis using  
high-level languages. It has 8 channels of audio I/O, a reasonable  
amount of program memory and is supported by another variant of GCC.  
Plus it runs pretty quick.

Lots of things to consider. Probably too many choices...

Eric


On Mar 5, 2008, at 5:01 PM, Julian wrote:

> Forgive me, as ive done very little external research on this before  
> asking here...
>
> I was chatting to someone last night about audio processing, and it  
> got onto microprocessors as a solution for 'wierd' stuff...
>
> I have a friend whose a professional C++ programmer, and has, for  
> his own fun, written several little 'windows' applications doing  
> things like genetic granular stuff.
>
> This would all have been using the standard windows, whatever their  
> called, drivers? dlls? - ie not writing to the hardware direct, but  
> to a sofware 'middle man'
>
> Anyway, im starting to digress..
>
> I was wondering as to how feasible it would be to convert this into  
> hardware?  What i should be reading, and what i should be asking him  
> (i have little experinace with C++ and he has little experiance of  
> electronics)
>
> Any pointers?