FAUSTLIVEJust-In-Time Faust Compiler... and much more

Sarah DENOUX and Stephane LETZ and Yann ORLAREY and Dominique FOBERGRAME

11 Cours de Verdun (GENSOUL)69002 LyonFRANCE

{sdenoux, letz, orlarey, fober}@grame.fr

Abstract

FaustLive is a standalone just-in-time Faustcompiler. It tries to bring together the conve-nience of a standalone interpreted language withthe efficiency of a compiled language. Basedon libfaust, a library that provides a full in-memory compilation chain, FaustLive doesn’trequire any external tool (compiler, linker, etc.)to translate Faust source code into binary ex-ecutable code.

Thanks to this technology, FaustLive pro-vides several advanced features. For exampleit is possible, while a Faust application is run-ning, to modify its behavior on-the-fly withoutany sound interruption. It is also possible to mi-grate a running application from one machine toanother, etc.

KeywordsAudio, Faust, DSP programming, remote process-ing and interfacing

1 Introduction

Faust [Functional Audio Stream] [6] is a func-tional, synchronous, domain-specific program-ming language specifically designed for real-time signal processing and synthesis. A uniquefeature of Faust, compared to other existingmusic languages like Max, PD, Supercollider,etc., is that programs are not interpreted, butfully compiled. Faust provides a high-levelalternative to C/C++ to implement efficientsample-level DSP algorithms.

But, if compilers have the advantage of ef-ficiency, they have their own drawbacks com-pared to interpreters. Compilers traditionallyrequire a whole chain of tools to be installed(compiler, linker, development libraries, etc.).For non-programmers this task can be com-plex. The development cycle, from the editionof the source code to a running application, ismuch longer with a compiler than with an inter-preter. This can be a problem in creative situ-

ations where quick experimentation is essential.Moreover, binary code is usually not compatibleacross platforms and operating systems.

FaustLive is an attempt to bring togetherthe convenience of a standalone interpreted lan-guage with the efficiency of a compiled lan-guage. Based on libfaust, a library that providesa full in-memory compilation chain, FaustLiveis a standalone application that doesn’t requireany external tool to translate Faust source codeinto binary executable code and run it. In manyaspects FaustLive behaves like a Faust inter-preter with a very short development cycle (notvery different, in that aspect, from modern com-piled LISP environments, or from the approachpresented by Albert Graef with Pure in [1]).

Moreover, FaustLive provides some advancedfeatures to speedup the development cycle. Forexample, while a Faust application is running,it is possible to edit and recompile its Faustcode on-the-fly, without any sound interruption.If the application is using JACK as driver, allaudio connections are maintained. Another in-teresting feature is the possibility to migrate arunning application from one machine to an-other through the network even across operat-ing systems. Applications can also be controlledremotely, using HTTP or OSC.

FaustLive offers a lot of flexibility to proto-type audio applications. It can also be con-nected to FaustWeb, a remote compilation ser-vice to export the application as a traditionalbinary for one of the various operating systemand audio architecture supported by the Faustecosystem.

Since FaustLive is based on libfaust, theFaust compiler project will first be presented(see Section 2). Then FaustLive will be shortlydescribed through a typical use case (see Sec-tion 3) to finally be detailed over its technicalaspects (see Section 4).

2 Faust Compiler

The Faust compiler translates a Faust pro-gram into an equivalent imperative program(typically C, C++, Java, etc.), taking care ofgenerating efficient code. The Faust packagealso includes various architecture files, provid-ing the glue between the generated code andthe external world (audio drivers and user in-terfaces).

Figure 1: Steps of Faust compilation chain

The current version of the Faust compilerproduces the resulting DSP code as a C++class, to be inserted in the architecture file. Theresulting C++ file is finally compiled with aregular C++ compiler to produce the final exe-cutable program or plug-in (Figure 1).

The resulting application is structured asshown in Figure 2. The DSP has become anaudio computation module. As for the archi-tecture, it turned into links to the user interfaceand the audio driver.

Figure 2: Faust application structure

2.1 LLVM

LLVM (formerly Low Level Virtual Machine) isa compiler infrastructure, designed for compile-time, link-time, run-time optimization of pro-grams written in arbitrary programming lan-

guages. Executable code is dynamically pro-duced using a “Just In Time” compiler from aspecific code representation, called LLVM IR1.Clang, the “LLVM native” C/C++/Objective-C compiler is a front-end for LLVM Compiler.It can, for instance, convert a C or C++ sourcefile into LLVM IR code (Figure 3).

Figure 3: LLVM compiler structure

Domain-specific languages like Faust caneasily target the LLVM IR. This has been doneby developing a special LLVM IR backend inthe Faust compiler, [5].

2.2 Dynamic compilation chain

The complete chain goes from the DSP sourcecode, compiled in LLVM IR using the LLVMbackend, to finally produce the executable codeusing the LLVM JIT. All steps are done in mem-ory. Pointers on executable functions can beretrieved in the resulting LLVM module, andtheir code directly called with the appropriateparameters.

In the faust2 development branch, the Faustcompiler has been packaged as an embeddablelibrary called libfaust, published with an asso-ciated API, [2]. This API imitates the conceptof oriented-object languages, like C++. Thestep of compilation, usually executed by gcc,is accessed through the function createDSP-Factory. Given a Faust source code (as a fileor a string), the compilation chain (Faust+ LLVM JIT) generates the “prototype” ofthe class, called llvm-dsp-factory. Then, thefunction createDSPInstance, corresponding tothe “new className” of C++, instantiatesa llvm-dsp. It can then be used as any ob-ject, run and be controlled through its interface.

Embedding this technology in a program ora plug-in enables dynamic modifications of theaudio computation module of a Faust applica-tion [4].

1The Intermediate Representation is an intermediateSSA representation

3 FaustLive - Use Case

FaustLive is a QT-based2 software that per-mits to launch Faust applications from theirsource code without having to precompile them(Figure 4).

Figure 4: FaustLive principle

FaustLive exploit dynamic compilation,associated with multiple interfacing systemsand audio drivers to modulate the structureof Faust applications and simplify Faustprototyping process.To give an idea of FaustLive’s potential, thefollowing section presents its diversified fea-tures, showing the corresponding alterations inthe structure of the applications.

The starting point of FaustLive’s features isdrag and drop. A Faust DSP can be openedin a new window or it can be dropped on arunning Faust application. As a result, anintermediate state emerges in which the twoapplications coexist. The arriving applicationcopies the established audio connections. Then,the output of the old application is cross-fadedto the new one (Figure 5). At last, the droppedapplication durably replaces the previous one.With that system, a running application canbe changed endlessly, without audio click.

This mechanism also allows source edition.When the user chooses to edit its Faust code,it is opened in a text editor. And as his changesare saved, the application is updated using thecrossfade mechanism (Figure 6).

2QT is a framework for interface design

Figure 5: Behavior modification

Figure 6: Dynamic source edition

JACK was primitively adopted as audiodriver for it allows the user to connect itsFaust applications between themselves. Otherdrivers have then been added, making thiscomponent of the structure as flexible asthe others. So when Faust applications arerunning, FaustLive gives the possibility todynamically switch the audio driver. FaustLivedoes not need to be stopped. The migration ismade during execution and is applied to everyFaust application running. JACK, NetJack,CoreAudio and PortAudio are the integrateddrivers in FaustLive (Figure 7).

Figure 7: Dynamic driver migration

FaustLive expands its radius of action to ex-ternal interactions. A smartphone can open anOSC3 interface, controlling the application re-motely (Figure 8).

Likewise, a HTML interface is accessiblethrough a Qr Code4. By scanning it with a

3OSC : Open Sound Control4QR code (abbreviated from Quick Response Code)

is the trademark for a type of matrix barcode (or two-

Figure 8: OSC interface

touchpad (for instance), the remote interfaceis opened in a browser. In both cases, theinterface is duplicated and a synchronizationbetween the local and remote interface isestablished.

The HTML interface has an additionalinterest: it is set up to enable drag and drop.Therefore, the user controlling the remoteinterface can also change the behavior of theapplication by dropping his own DSP. It is sentto the local application where it replaces therunning one, using the crossfade mechanism.Finally, the remote interface is updated (Figure9).

If many or/and heavy Faust applicationsare opened, local CPU load can be saturated.The migration of calculations to other machinescan lighten this load. On account of dynamiccompilation, the audio computation modulecan be relocated on another machine (Figure10). The list of remote servers available is builtdynamically so that it is simple to switch fromlocal processing to remote processing.

A user may wish to run his Faust appli-cation in an other environment (Max/MSP,SuperCollider, ...). For that matter, a link toFaustWeb, a remote compilation web service, isintegrated in FaustLive. The user only has tochoose the platform and environment he wishesto target. In return, he will receive the binaryof the requested application or plugin.

When FaustLive is exited, the last configu-ration is saved and will be restored at its next

dimensional barcode)

Figure 9: Remote drop

Figure 10: Remote processing

execution. A user may also save the state ofthe application at any moment. In a secondphase, he will be able to reload his snapshot,by importing it in the current state or recallingit (Figure 11).

Figure 11: Reloading snapshot

4 FaustLive - Technical View

4.1 Basic FaustLive Features

The first aim of FaustLive is to create a dynamicenvironment for Faust prototyping, by embed-ding libfaust. The resulting dynamic compila-tion chain (Figure 12) presents the advantageof speeding up the compilation process. Return-ing almost right away the executed application,this compiler is a stepping stone for dynamicbehaviors.

Figure 12: Compilation chain in FaustLive

Now that it is possible to dynamicallycompile Faust code, new prospects are rising.A user may drop his Faust code as a file, astring or a url, on a running application. Asa result, the code is immediately given to theembedded compiler and the new applicationreplaces the previous one. Since FaustLive isdesigned for dynamic uses, it is very importantto ensure a continuity in the sound. For thatmatter, a crossfade is calculated between thetwo relaying Faust applications.

Moreover, a Faust application is linked toits source, so that any modification in the

Faust code will lead to a recompilation. Thisparticular aspect is central, for it simplifiesthe prototyping process: a user can modify hiscode at leisure and see/hear instantly the result.

An important asset of FaustLive is the coex-istence of multiple Faust applications, in op-position with the QT-JACK architecture fromFaust “static” distribution, where every Faustprogram has to be compiled separately to pro-duce its own application. Here, each applicationevolves with the actions it undergoes and has itsown set of dynamic parameters (Figure 13).

Figure 13: FaustLive’s environment

4.2 Audio Drivers

FaustLive has integrated JACK, CoreAudio,NetJack and PortAudio5. So that it’s possibleto switch audio structures or modify its pa-rameters (such as buffer size or sample rate)during FaustLive’s execution. Every runningaudio client is stopped, then the applicationsare transferred in the new domain to finally berestarted.

4.2.1 JACK

JACK is a system for handling real-time,low latency audio (and MIDI). It runs onGNU/Linux, Solaris, FreeBSD, OS X and Win-dows. It can connect a number of different ap-plications to an audio device, as well as allowingthem to share audio between themselves.

5JACK, CoreAudio and NetJack are used on OSX,JACK and NetJack on Linux, PortAudio, JACK andNetJack on Windows.

Therefore, an interesting constraint in usingJACK is the matter of the connections. Whenconnections have been established, the objec-tive is to maintain them even if the Faustapplication changes in a window. If the newapplication has more ports than the previousone, the user will have to make the connectionshimself.

4.2.2 NetJack

NetJack is a Realtime Audio Transport overa generic IP Network, fully integrated intoJACK. NetJack synchronizes all clients to onesoundcard, so there is no resampling or glitchesin the whole network. The master imposes thesample rate and buffer size, in relation to itsaudio device.

4.2.3 CoreAudio and PortAudio

Because the protocol has to be strictly the sameon the client and on the server’s side, JACK andNetJack have to be linked as a dynamic library.The problem it brings is that FaustLive’s in-stallation is linked to JACK’s installation. Toavoid this inconvenience for beginner users, aCoreAudio6 and PortAudio7 versions have beendeveloped. Included in the standard libraries oreasily linked as a dll, they do not expand theuser’s work.

4.3 Control Interfaces

To offer a modular application, FaustLiveexpands the choices of the user, concerning thecontrol interface.

4.3.1 OSC Interface

OSC protocol is integrated to FaustLive tooffer another type of interface and enableinteroperability. Many audio environmentsand devices implement this protocol so thatFaustLive will be able to communicate withthem. The user can configure the port onwhich the protocol is started and then controlthe interface with, for instance, an OSC touchapplication.

6CoreAudio is the digital audio infrastructure of iOSand OS X. It provides a framework designed to handleaudio needs in applications.

7PortAudio is a free, cross-platform, open-source,C/C++ audio I/O library. It is intended to promotethe exchange of audio software between developers ondifferent platforms.

4.3.2 HTML Interface

Faust HTML interface is also a component ofFaustLive. Loaded on any browser, this inter-face controls the DSP’s parameters, through aHTTP connection. When it is built, a serveris started, taking care of delivering the HTMLpage (Figure 14). A synchronization betweenthe local and the remote interface is also in-sured.

To ease the opening of the interface, a QrCode is built from the HTTP address, thanksto libqrencode. Most smartphones and portableequipments have a QrCode decoder. By scan-ning the Qr Code, a browser gets connected tothe interface page.

4.3.3 Preferences

The challenge FaustLive was confronted withis to provide an interface that gives as manyliberties as possible to the user all the whilebeing easy to apprehend. In that direction,OSC and HTTP ports are configurable inthe window’s options. The window toolbaris collapsed, by default, so that a “basic”user won’t feel assailed by preferences (Figure13). Both protocols use 5510 as default port.When the TCP listening port number is busy,the system automatically looks for the nextavailable port number.

!!

"#$%&#!'(%))*+,!-(#-! "#$%&#!.%+&(%/!*+&#(0-.#!

12//!3&$/!)-,#!

Figure 14: HTML interface with control anddropping services

4.3.4 Remote Drag and Drop

As the rest of Faust current distribution,the HTML interface has a “static” behavior.

The intention, to copy FaustLive’s dynamicbehavior, led to adding a dropping area tothe HTML interface. This HTTP service isindependent and specific to FaustLive. Theserver, started by FaustLive, is able to createa HTML page that encapsulates the remote in-terfaces. The resulting service of remote inter-face and DSP drop has the following address:http://IP:DroppingPort/InterfacePort (Figure14).

The dropping port is set in the preferencesand is common to all the Faust applications.The remote interface port is distinct for everyFaust application and editable in the window’soptions.

The reaction to the drop follows FaustLive’smodel. The DSP is first sent to FaustLive as aHTTP post request. The DSP is compiled andreplaces the previous one, after the crossfade.At last, the remote interface is updated.

4.4 Remote Processing

To widen its benefits, FaustLive enables remoteprocessing. The compilation and processcalculation are redirected on a remote machineand local CPU load can be lightened.

On a remote machine, an application startsa HTTP server, offering the remote compila-tion/processing service. This server is waitingfor requests.

On the client’s side (FaustLive), an API“proxy” makes it transparent to create aremote-dsp rather than a local llvm-dsp (c.f2.2). This API, libfaustremote, takes care ofestablishing the connection with the server.

The first step (compilation) is carried outby the function createRemoteDSPFactory. Thecode is sent to the server, which compiles itand creates the “real” llvm-dsp-factory. Theremote-dsp-factory returned to the user is animage of the “real” factory. Before sending theFaust code, a Faust to Faust compilationstep is executed locally, to solve all the depen-dencies. This way, the expanded code sent tothe server is self-contained.

The remote-dsp-factory can then be instan-tiated to create remote-dsp instances, whichmay run in the audio/visual architecture cho-sen (here, FaustLive).

To be able to locally create the interface, theserver returns a json-encoded interface. This

way, the function buildUserInterface can berecreated, giving the impression that a remote-dsp works as a local llvm-dsp.

Moreover, the audio processing is redirectedthrough a NetJack connection. The audio datais sent to the remote machine which processesit and sends back its results. In addition tothe standard audio flow, one midi port is usedto transfer the controllers values (Figure 15).The benefit of this solution is to transmitsynchronized audio and controllers in the sameconnection. Moreover, the audio samples canbe encoded using the different possible audiodata types : float, integer, and compressedaudio (using the OPUS codec8).

Figure 15: Remote compilation

libfaustremote uses libcurl to send httprequests to the remote server, handled withlibmicrohttpd.

On FaustLive’s windows, the service of re-mote processing is simply interfaced. The Zero-Conf protocol is used to scan the remote ma-chines presenting the service. A list is thendynamically built with the available ones. Bybrowsing in the list, the user can then switchfrom a machine to another or come back to lo-cal processing very easily.

4.5 FaustWeb

In order to simplify the accessibility of theFaust compilation, this web service of remotecompilation has been conceived. It receives aFaust DSP and returns a plugin or applica-tion in the chosen target architecture. As anoutcome, the installation of Faust package andall additional SDKs on the user machine is notnecessary anymore. Anyone can write a Faust

8http://www.opus-codec.org

application, send it to the server and receive aplugin.

This service is accessible from a browser butrequires several requests. Through FaustLive,the export is facilitated. A menu is dynami-cally built with the platforms and architecturesavailable. And as the user makes his choice,his code is sent to the server. The first step isthe syntax verification, returning a sha1 key,with which multiple requests can be made.The second step is the compilation, usingthe standard “static” chain and returning thechosen application to the user (Figure 16).

!

"#$%&'!()%!!$*$+,$-,#!.$%/#.0!

123!43$%/#.0!

5+0.!)(!.$%/#.0!

!"#$%&'()* !"#$%+),*

!

"#$%&%'()%*+!*&!!&(,-)!-.+)(/!

!0$#()%*+!*&!

,+%1,#!-2(345#.!&*$!)2#!6-7!

!

89:;!<6-7!&%=#!

-2(345#.!

0*>7%=()%*+!&*$!'2*-#+!

($'2%)#'),$#!

?@;!<5#.<7=()&*$>!<($'2%)#'),$#!

A%+($.!&%=#!

Figure 16: Steps of the compilation chainthrough FaustWeb

4.6 Session Management

A concept of session is introduced to preservethe state of the application (parameters values,position on screen, audio connections, compila-tion options, ...) when the application is closedor when the user takes a snapshot, which saveshis session in a .tar file.

A FaustLive snapshot is self-contained. Allthe local resources needed (like Faust DSPs)are copied into the folder. Pointers to the re-sources are used as much as possible. But ifa source file is erased or the snapshot is trans-ferred on another machine, copies ought to beemployed.

To decrease the compilation time, the out-put of Faust compiler, the optimized LLVMIR code, is saved. When the application is re-called, Faust compiler’s and LLVM IR to IRoptimization steps are skipped. For very heavyprograms, the gain can be noticeable (from afew seconds to almost instantaneous).

5 Conclusion

FaustLive brings together the convenience of astandalone interpreted language with the effi-ciency of a compiled language.

FaustLive offers currently the shortest de-velopment cycle for Faust applications, allow-ing even to modify the code of an applicationwhile it is running. It integrates advanced re-mote computation and control features for real-time distributed audio applications. MoreoverFaustLive provides, via its export functionality,a convenient front-end for FaustWeb, the com-pilation web service of Faust. The project isopen-source and available on Sourceforge [3]. Itruns on Linux, OSX and Windows.

AcknowledgmentsThis work has been implemented for one partunder the INEDIT project [ANR-12-CORD-0009] and for the other part under the FEVERproject [ANR-13-BS02-0008]. It is supported bythe “Agence Nationale pour la Recherche” .

References

[1] A. Graef. Functional signal processing withpure and faust using the llvm toolkit. 2011.

[2] faust2 repository.http://sourceforge.net/p/faudiostream/code/ci/faust2/tree/.

[3] faustlive repository.http://sourceforge.net/p/faudiostream/faustlive/ci/master/tree.

[4] S. Letz, Y. Orlarey, and D Fober. Commentembarquer le compilateur faust dans vos ap-plications? 2013.

[5] S. Letz, Y. Orlarey, and D Fober. Dynamiccompilation of parallel audio applications.2013.

[6] Y. Orlarey, S. Letz, and D. Fober. Faust:an efficient functional approach to dsp pro-gramming. 2009.