JUCE plugins in WebAssembly


I’ve ported JUCE AudioProcessor and friends to WebAssembly and AudioWorklet. The port turned out to be quite straight forward, and consists of three modules: core, events and audio (fusing audio_basics and audio_plugin_client).

AudioWorklet is pretty cool as it lives in browser’s audio thread, and with 128 sample buffer size latency is at decent levels. However, since it runs in a sandbox (worklet) inside a sandbox (browser), JUCE features need to be split in two parts: DSP in worklet and GUI + other stuff in browser’s main thread or web worker.

The port is still unoptimized, I’m learning as I go on. More info and couple of JUCE plugin demos are at the links below. We are targeting a community controlled open API to run VST-like plugins in browsers. Would be great to hear your feedback!

Or if you have a JUCE plugin that you’d like to port and need help, let me know. The only thing that needed to be changed in plugin DSP code was to comment out the GUI. GUI port required most effort for sure, but that was kind of fun as well. Yes, I’m a geek.

Please note that the demos require latest Chrome canary (64.0.3275 or later).

WAMs community site



Here’s DEXED demo:



1 Like

here’s what it should look like in chrome canary, once you have enabled experimental web features:


1 Like

and a VA synth for good measure:

How soon till we have a browser based DAW?

Great question! I work with AmpedStudio, and we do have plans to support WAMs in near future. Sorry I cannot give exact dates yet. Our DAW runs in Chrome, and it is available at the address below if you want to try it out (pls click the circular A logo to launch the app).



1 Like

Hello Jari,

your project looks very exciting!
I’m interested in porting an audio effect plug-in written in JUCE to WASM, so users can run it in their browser. Can you explain how exactly I should proceed? I haven’t found any implementation details regarding JUCE on your website.

cool! i will talk about porting juce online at the forthcoming adc, but in the meantime i’ve started cleaning up the existing obxd port, and will write here when it is at github. together with some documentation, sorry about that :slight_smile:

1 Like

Thanks, I’m looking forward to that! :slight_smile:

Pushed webOBXD sources to https://github.com/jariseon/webOBXD and added some documentation for the porting process, plus comments in the code. After cleaning up i was kind of surprised that OBXD code actually required only couple of tweaks to make the DSP part run online (see this commit).


Thank you very much for your effort! This does not seem too complex at all, and I am excited to try this out!
The most complex part of my Software is the GUI, though, I have an advanced MIDI-grid-like editor with different tools and all, which I definitely don’t want to rewrite in JS.
If I wanted to help porting the JUCE Component classes to WASM, what would I need to do? I assume, one would need to implement bridges between JS events and MouseListeners, etc, right?

sounds like @pixelpacker has already done that: Compiling Juce with Emscripten

I’ve experimented with canvas and webgl graphics implementations, and currently preferring the webgl one. I bet the JUCE OpenGL Graphics Context could be ported fairly easily using emscripten’s GLFW library. You can try my synth here: https://virtualcz.io, currently audio is only working in chrome.

1 Like

Was the synth you linked compiled for web using @pixelpacker’s technique, or have you rolled your own WASM/JUCE bridge? In any case, if you’re using the original JUCE GUI code in the browser, that’s promising.

VirtualCZ is done with iPlug 2, but the basic principles are the same.

@pixelpacker’s SharedArrayBuffer (SAB) technique sounds really interesting as it allows - if i’m not mistaken - to run the gui in a web worker. My current solution runs the wasm’d juce gui on main thread, albeit with direct access to HTML5 canvas backend. so far the results have been quite promising, not much (if any) tweaking required for custom AudioProcessorEditor/Components. though there’s still room for optimizations.

i’ll do my best to measure the cpu load of each technique for adc (i.e., SAB, direct canvas/webgl, svg/dom elements as a baseline).


So you are working on porting JUCE GUI to WASM? Cool!