Re: [LAD] Project proposition: llvm based dsp engine - Linux-audio-dev

7 Dec 2010

Le 7 déc. 2010 à 13:00, linux-audio-dev-request(a)lists.linuxaudio.org a écrit :
...

 Message: 6
 Date: Tue, 07 Dec 2010 11:40:08 +0100
 From: Maurizio De Cecco &lt;jmax(a)dececco.name&gt;
 Subject: Re: [LAD] Project proposition: llvm based dsp engine
 To: linux-audio-dev(a)lists.linuxaudio.org
 Message-ID: &lt;1291718408-fa0519db02fe30b9a7fa6ef94f6d44d6(a)dececco.name&gt;
 Content-Type: text/plain; charset="iso-8859-1"

 I realised that my yesterday answer miss the point a little,
 so here it is a few linse of complement.

 Going back to the Paul comment:

  I can say for sure that, for example,
 Ardour3 has an object called a Processor whose ::run() method
 encapsulates all DSP done within Ardour, but nevertheless it would be
 more or less impossible to do any kind of optimization that looked
 "across" all the Processors in a signal chain (eg. gain, pan, plugins,
 etc, etc).  
 This is exactly the point: what about having a way to build the 'run' methods
 for a class of applications (PD have such a method, jMax have such a method, 
 many others application have such a methods) that *would* allow cross plugin 
 optimisations for a certain class of plugins (those written or compiled according
 to the engine 'native' rules) and being able to use the other plugins keeping
the
 glue code run time cost very low thanks to dynamic code generation.

 Essentially a generic basic infrastructure using LLVM code generation and optimisation
 capabilities.

 And by the way, i am not sure to understand the reference to Faust, that is one of the
 language/system used to define and assemble DSP algorithms, and to generate plugins,
 but it is not a generic container for DSP executions, AFAIK.

 Maurizio

Doing "cross plugin optimisations" is something that can be done at the Faust
source code level, where sophisticated optimization and code reorganisation can be done
because we stay at a pure functional signal level, thus avoiding all the complex issues
related to state management. If you want to combine plug-ins coded in any kind of
imperative language, then some really hairy issues are coming quite rapidly.

Stéphane 