Ayan Shafqat (Mar 18 2026 at 14:51): Ayan Shafqat (Mar 18 2026 at 14:51):Hello everyone! I have been working on a small experiment exploring whether WebAssembly can serve as a more portable plugin format for Digital Audio Workstations (DAW), using the existing LV2 plugin API.
The idea is to compile the plugins to wasm32-wasip1 and then execute it inside a native DAW using Wasmtime.
The main challenges I’m running into are preserving the real-time constraints expected by audio hosts, and figuring out a viable path for plugin GUIs.
I have put together an early proof-of-concept here: https://github.com/Colahall/lv2-wasm
Since I am very new to Wasmtime and WASI in general, I’d really appreciate any feedback or pointers, especially around:
I understand this is a bit outside typical WASI workloads, but I’m curious how far this direction can be pushed.
Alex Crichton (Mar 31 2026 at 18:44):A bit of a late response, but some thoughts I can offer are:
Best practices for host to guest memory sharing (e.g. low-latency audio buffers)
I'd recommend looking into component model resources and compile-time-builtins in Wasmtime for this.
Whether Wasmtime is suitable for real-time / low-latency workloads
You'll probably need to do your own analysis for this one. Wasmtime isn't specifically designed for this, but it's also not specifically designed to be bad at it. Anything awry is likely a bug and something that would be good to fix.
Patterns for instance reuse, threading, or avoiding allocation/latency spikes
For the smoothest time, ish, you'll want to avoid threading for now. Otherwise this depends on your plugin architecture and application mostly as to whether new instances or reusing instances makes sense.
Any other prior works for platform-agnostic graphics API used within Wasmtime
I'd recommend looking around for wasi:gpu or wasi:webgpu (I think?)
Bailey Hayes (Apr 03 2026 at 21:16):home of projects for the WebGPU impl: https://github.com/wasi-gfx
Last updated: Apr 12 2026 at 23:10 UTC