Plugin types

ViveEngine supports two kinds of plugins: native and managed. They differ in where they run, how much overhead they add, and what they're allowed to do.

Pick based on which goal matters more for your plugin:

Native — prioritizes efficiency. Use it for real-time effects that need zero added latency, but expect more limits and more implementation complexity.
Managed — prioritizes flexibility and productivity. Use it for heavier or less time-critical work, with process isolation and higher-level languages, at the cost of extra latency.

The rest of this page covers each type in detail and ends with a side-by-side comparison.

Native plugins

Native plugins are loaded directly into the engine and run inside the real-time audio pipeline. They're the fastest option, but that speed comes with strict requirements.

Zero overhead

A native plugin runs in-process, so there's no inter-process communication and no extra latency. The only cost is your own processing time. This makes native plugins the right choice for latency-sensitive effects like noise suppression or voice transformation.

Shared address space

The plugin is loaded into the engine's address space and shares memory with it. That means a bug in the plugin can take the engine down with it:

A crash brings down the engine process.
Memory corruption can affect unrelated parts of the engine.
A memory leak accumulates in the engine, not in an isolated process.

Because of this, native plugins are held to a high standard of stability.

Real-time context

Frame processing runs on the real-time audio thread. That thread has a hard deadline: if it's late, audio glitches. So the plugin must follow real-time rules.

Don't block. No waiting on locks, I/O, or anything with unbounded latency.
Be fast. Keep per-frame work short and predictable.
Avoid priority inversion.

What is priority inversion?

Priority inversion happens when the high-priority audio thread waits on a lock held by a lower-priority thread. If that lower-priority thread gets preempted, the audio thread is stuck waiting behind it, and audio stalls.

Avoid it by not sharing locks between the audio thread and non-real-time threads. Prefer lock-free structures for passing data in and out of the processing callback.

Security restrictions

What the plugin is allowed to do depends on the platform:

Windows — the plugin runs inside the OS driver sandbox. It has no network access, and only limited access to IPC and the filesystem.
macOS — the plugin currently runs in a regular context. This may change in the future if specific optimizations require a more restricted runtime context.

What is the driver sandbox?

On Windows, native plugins run inside AudioDG, the protected system process that hosts audio driver processing. This keeps audio processing isolated from regular user applications, but it also means plugins run with tighter restrictions than normal app code.

See Microsoft's Audio Processing Object architecture documentation for more background.

Since the plugin can't rely on reaching the outside world on its own, it should use the engine to talk to the application. The message callbacks let the plugin exchange out-of-band messages with the app through the engine instead of opening its own channels.

Compatibility

Native plugins are built as shared libraries and loaded dynamically by the engine:

Compiled language. Write the plugin in C/C++ or any language that can expose a C ABI and run without an external runtime.
ABI compatibility. The plugin must match the engine's calling convention and structure layout so the exported functions and shared structs line up. On Windows, only release builds are allowed — the AudioDG sandbox won't load debug builds.

Managed plugins

In development

Managed plugins are currently in development. Feel free to contact us if you're interested.

Managed plugins run in a separate process and communicate with the engine over shared memory. They trade a little latency for isolation and flexibility.

IPC overhead

Audio is passed to the plugin through shared memory, which adds a small amount of latency. That's the price of running out of process. For work that does not need native-plugin timing, it's often a fine trade-off.

Isolated address space

Managed plugins run outside the engine, in bridge processes. A bridge is a separate process that hosts one or more plugins. The isolation contains failures:

A crash affects only the plugin, not the engine.
A memory leak stays in the plugin's process.

Relaxed real-time requirements

A managed plugin is not called directly from the engine's real-time audio thread. If it's slow, only that specific plugin stage is affected — the rest of the pipeline keeps running. This relaxes the strict timing rules that native plugins have to follow.

Relaxed security restrictions

Managed plugins run in normal processes, without the sandbox restrictions that apply to native plugins. On Windows they run under the system user, on macOS under the current user.

Without the sandbox, a managed plugin can use the network, the filesystem, and other system resources. This makes it a good fit for cloud APIs, transcription, streaming, and analytics.

Diverse languages choice

Managed plugins can be written in different languages. Each language has its own bridge that connects the plugin process to the engine, plus a library that helps integrate your code into the bridge.

Comparison

Aspect	Native	Managed
Where it runs	In the engine address space	In a separate bridge process
Overhead	Zero	Several milliseconds
Isolation	None — a bug can crash the engine	Full — failures stay in the plugin
Real-time pipeline	Runs directly in it; must be fast and non-blocking	Not called directly from the real-time audio thread; slowness affects only that plugin stage
Restrictions	Windows: AudioDG sandbox (no network, limited IPC/filesystem), macOS: none for now	None: network, filesystem, etc.
Language	Compiled, C ABI (C/C++)	High-level
Best for	Real-time effects like noise suppression or voice transformation	Cloud APIs, transcription, streaming, analytics