Is it Possible Static link Tracktion Engine (JUCE) in Electron Main Process?

General JUCE discussion
1

Hi everyone,

I’m planning to integrate Tracktion Engine into an Electron application by building Tracktion Engine as a static library and linking it directly into the Electron source code, specifically to be used within the Electron main process.

Before diving deeper, I want to clarify my context and constraints to focus the discussion:

  1. Build & Linking: I am experienced with building Electron from source and linking native static libraries. The process of building and linking Tracktion Engine this way is not my concern.
  2. UI Approach: I will be using Tracktion Engine in a “headless” manner. I will not be using the JUCE UI framework provided by Tracktion Engine or JUCE itself. Any necessary UI will be built using standard Electron techniques (e.g., JavaScript in the main process calling the C++ Tracktion Engine functions, then communicating with the renderer process). Therefore, potential issues related to integrating JUCE’s UI components or message loop with Electron’s are not my primary concern here.

My Core Question & Primary Concern:

My absolute main focus and concern is the stability and quality of the real-time audio processing.

Specifically, I need to understand the viability and risks of running Tracktion Engine’s (and therefore JUCE’s) high-priority, real-time audio thread directly within the Electron main process. This process simultaneously runs the Node.js event loop and the V8 JavaScript engine.

  • How likely is interference from the Node.js environment – such as event loop activity, background tasks managed by libuv, and particularly V8 Garbage Collection pauses (“Stop-the-World”) – to disrupt the precise, low-latency scheduling required by the audio thread?
  • My application demands high audio stability and pristine audio quality. Is running the audio thread within the same process space as Node.js/V8 fundamentally incompatible with these requirements, potentially leading to unavoidable glitches, dropouts, or increased latency in practice?

Other Potential Pitfalls?

Given that I’m handling the build/linking and explicitly avoiding JUCE UI integration issues, are there any other significant, non-obvious pitfalls specific to running headless Tracktion Engine within the Electron main process that I should be aware of, beyond the core audio stability concern?

2
  • How likely is interference from the Node.js environment – such as event loop activity, background tasks managed by libuv, and particularly V8 Garbage Collection pauses (“Stop-the-World”) – to disrupt the precise, low-latency scheduling required by the audio thread?

Very high. You will have to finely tune your Javascript code to ensure that big heap allocations do not impact performance.

. Is running the audio thread within the same process space as Node.js/V8 fundamentally incompatible with these requirements, potentially leading to unavoidable glitches, dropouts, or increased latency in practice?

Yes, this is a messy headache that is going to be very difficult to keep performant.

You are definitely going to run into issues with garbage collection interfering with things if you try to integrate tracktion_engines threading with Electrons’ threads.

These should be kept as far away from each other as possible - so the best approach would be to put all the engine code in its own separate native process - i.e. a ‘daemon’ that your app fires up and communicates with via IPC.

The question is, what do you gain from doing things this way? Faster UI development with cheaper/more common resources? Not worth it, imho. Bite the bullet and learn to write JUCE UI code…

3

I’ve not used Electron myself but I would like to point out that TE isn’t ties to using a JUCE UI.
We have users building Qt, React and HTML/JS web component based apps.

Tracktion Engine/JUCE starts its own audio threads and attaches them to the system device so as long as you don’t accidentally do any JS allocation on those, I think they should continue to run even as the GC runs.

I know there can be some shenanigans to get the React/Node/Qt etc. message loop to run nicely with the juce one but this can be done.