[LAD] Project proposition: llvm based dsp engine

Stéphane Letz letz at grame.fr
Tue Dec 7 13:28:01 UTC 2010

Le 7 déc. 2010 à 13:00, linux-audio-dev-request at lists.linuxaudio.org a écrit :
> Message: 6
> Date: Tue, 07 Dec 2010 11:40:08 +0100
> From: Maurizio De Cecco <jmax at dececco.name>
> Subject: Re: [LAD] Project proposition: llvm based dsp engine
> To: linux-audio-dev at lists.linuxaudio.org
> Message-ID: <1291718408-fa0519db02fe30b9a7fa6ef94f6d44d6 at dececco.name>
> 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.


More information about the Linux-audio-dev mailing list