[sdiy] Newbie code porting question

[Justin Owen]

Thanks Brian - interesting answer.

I should have pointed out this isn't something I was considering doing myself. I was more interested in the feasibility of the concept. 

Seems like maybe it's feasible, maybe it's not - good odds!

Cheers,

J




-----Original Message-----
From:  [rsdio at sounds.wa.com]
Received: 25.04.2013 22:26:12
To: Justin Owen
Cc: SDIY List
Subject: Re: [sdiy] Newbie code porting question


On Apr 25, 2013, at 09:30, Justin Owen wrote:
> Brian Willoughby touched on a point I've been meaning to ask for  
> ages...
>
> "...porting a VST from a DAW to an embedded, battery-powered
> platform is much, much harder than porting a VST to AU"
>
> In general, is it feasible to consider porting code from software  
> e.g. a plug-in or an app to code used in embedded hardware or (in  
> general) would there be so little common ground between the two  
> sets of code (or the two platforms) that you'd (generally) be  
> better off starting with code dedicated to the platform you were  
> running?

If you're just starting, then think of the porting process as  
multiple steps.

First, you need to become familiar with the original code. In that  
sense, it's probably quite worthwhile for a new programmer to study  
existing code to the point where it is mostly understood.  
Unfortunately, this should probably be done in the original  
environment, e.g., VST host, and thus it's not porting at this stage.  
But if you can gain an understanding of the existing code, then  
you'll probably learn a lot about the DSP techniques involved.

Second, you need to really understand the strengths and weaknesses of  
the target platform. These are less about the task at hand and more  
about the general capabilities. Is there DMA? Is the CPU fast enough  
to respond to an interrupt per sample? What is the overhead of the  
interrupt call on this particular processor? Are there ramifications  
to doing major work in an interrupt routine? What is the operating  
system that you'll use, if any at all?

After studying both sides of the equation, you'll know whether the  
specific porting process you're considering has enough common ground  
to make the effort worthwhile. If there is too little common ground,  
at least you now fully understand the original code, and can perhaps  
rewrite the algorithms from scratch (or from building blocks  
available on the target platform) using that new knowledge. If there  
is common ground, you'll probably have a much better chance fitting  
the pieces into the new system.

DSP often involves some heavy weight math subroutines that are  
generally available on every platform. I've even ported VST code  
where the operating system and DAW stayed the same, but the math  
libraries changes. Apple offers Accelerate.framework and vecLib,  
supporting multiple processors. Intel offers common DSP that  
leverages SSE for optimization. Embedded systems hopefully implement  
these same math functions, but if they don't then you'll need to pull  
them together yourself. This is just one example where understanding  
high-level concepts about DSP allows you to swap out equivalent  
pieces even though the overall C code remains largely unchanged. In  
fact, optimization is one major area where code might not be  
portable, because what is optimal for one platform might be terribly  
inefficient for another.

You can't learn this without diving in, but I'd suggest working on  
open source "in place" for a while in order to become familiar with  
it before trying to port to a new platform. You can also play around  
with simpler code on the new platform until you're ready to try to  
get a large code base running.

Brian Willoughby
Sound Consulting