[sdiy] Raspberry Pi 2 Synthesizer Project

[Scott Gravenhorst]

Eric Brombaugh <ebrombaugh1 at cox.net> wrote:
 >
 >On Feb 7, 2016, at 6:49 AM, Scott Gravenhorst wrote:
 >
 >> Richie Burnett <rburnett at richieburnett.co.uk> wrote:
 >> >Sounds good. What did you write the code in? Assembly, C, python?
 >>
 >> The code is written entirely in C. It's pretty much raw
 >unoptimized code, so performance could increase with more
 >attention to that. Once I learn ARM assembly language (a bit more
 >complex than PIC/dsPIC) I may include some of that for tightness.
 >The synth currently has no GUI, so it can run headless if needed.
 >I'm thinking about adding another different synth to make it
 >bi-timbral, and eventually I'll add effects.
 >
 >I'd be interested to find out if you have any success with
 >optimizing via hand-written assembly language. Like you, I
 >started my DSP work in dsPIC assembly and felt pretty competent
 >at wringing the most from that architecture. Lately though I've
 >been doing a fair amount of ARM-based synth coding using GCC and
 >have made several stabs at assembly without being able to improve
 >on the performance of optimized C. Digging into the disassembled
 >C code it becomes obvious that the compiler is doing a fair
 >amount of loop unrolling and interleaving to make maximum use of
 >pipeline latencies. Keeping track of pipeline requirements while
 >hand-coding assembly seems like it would be pretty difficult,
 >especially given that the exact nature of the pipeline changes
 >from one ARM architecture to another, and I find myself using a
 >variety of CPUs in different projects.
 >
 >In the end I've concluded that for the sake of productivity it's
 >better to write my C code carefully and try a couple optimization
 >settings in the compiler, using the one that performs best (the
 >results seem to vary from project to project and between compiler
 >versions) rather than worry too much about the minutiae of the
 >assembly. I suspect that even it I were able to improve on the
 >compiler's results the gains would be fairly minor.
 >
 >Eric

Oh thanks for the heads up - I'd read that C compilers can do a good job 
of optimizing these days.  My original plan was to go bare metal, but 
after seeing how fiddly the process of getting code into the pi was, I 
decided to try this under Linux and just see how bad/good it is. 
Perhaps the assembly thing isn't worth the effort.  I'll need to write 
more feature rich synth apps to assess that, but this is looking very 
good.  And don't laugh, but I've actually developed the whole thing on 
the Rpi2 itself.  (I stuck a portable USB HD on it and moved the whole 
file system there except for /boot to reduce the wear and tear on the 
micro SD card)

It also uses the console UART with an optoisolator (console functions 
disabled) for MIDI input instead of a USB MIDI device.

Achim wrote this:
 >For that kind of code it should be beneficial to use VFPv4 and NEONv2, 
 >which is available on the Pi2.

Yes, I saw that NEON is in the IC, but I need to research how to turn it 
on with gcc as I believe it is not used by default.  It would be 
interesting to see if there's much of a difference.  In the past, all of 
my synth designs (such as for dsPIC and FPGA) have used fixed point 
format.  This particular synth uses the sin() function with uses double 
float arithmetic.  Voice summing is done with fixed pt.  A future KS 
synth will be float or double at first and then converted to fixed point 
just to see if there's a significant difference.

-- ScottG