Technical Summary

The basic Digital Audio Workstation (DAW) software architecture supports plug-ins—dynamically-linked software units which either generate or process audio data. Each plug-in typically contains two mostly-distinct parts which we refer to as Graphical User Interface (GUI) and the Digital Signal Processing (DSP).

The DAW program supports any number of plug-in instances in the memory of a single computer. Advanced plug-ins often place heavy demands on the computer's CPU, so there are practical limits to DSP setups.

To reduce the CPU burden, specialized DSP-acceleration hardware can be added to the DAW computer, but this is expensive, not only due to the cost of the hardware, but because it significantly raises software-development costs.

The author proposes that similar benefits can be obtained at far less cost using ordinary computers—commodity hardware—by allowing each plug-in's DSP code to run either locally (on the DAW computer, in the usual way), or remotely, in the form of a network service running on another computer on the same high-speed local-area network (LAN).

This approach offers several benefits:

• There is no need to rewrite or re-optimize DSP code for unconventional hardware.
• Because only the DSP code runs remotely (not the GUI), the secondary computer(s) can run "headless" (no screen, keyboard or mouse needed) in a separate room, which may include soundproofing, air conditioning, etc. which would be too noisy for the recording studio.
• Because the secondary computers (which we will call servers) require no graphics or audio I/O hardware, they also have no need for proprietary operating systems such as Microsoft Windows or Apple macOS; Linux is sufficient.
• Most important of all, the standard single-computer DAW architecture is no longer a limitation. The amount of available CPU power for DSP is limited only by the user's budget, and can be expanded at any time.
• In a large studio, multiple DAW sessions can be simultaneously supported on a shared "cluster" of DSP servers. Because a single DSP code implementation suffices for different versions of the same plug-in (e.g. Audio Units for macOS, VST for Windows), simultaneous sessions can use a mix of computer, operating system, and DAW software.

Audio latency was discussed at some length in the presentation. Latency is primarily an issue for live recording, where the monitor-mix provided to artists must not lag their live performance by more than a few milliseconds. Three basic techniques were suggested, the first of which has already been implemented by the author.

1. The plug-in remains one buffer behind the remote DSP module, so the effective latency is always exactly one buffer-interval (determined by DAW settings, no more than 12 milliseconds).

2. Chaining connected DSP modules on the server-side avoids unnecessary round-trip network communication, avoiding the resultant compounding latency.

3. Low-latency monitor mixes (for performer feedback during recording) can be computed on the server side, and fed back to the control room using standard connections (e.g. MADI or Audio-over-Ethernet).

These ideas are not new. Most were implemented in Apple's Logic Pro 7 DAW as early as 2004, but with no support for third-party plug-ins, its networking features went largely unused. The excellent Vienna Ensemble Pro 6 software provides remote access to plug-ins on networked computers, as does the author's NetVST project, but neither allows plug-in GUIs to remain local to the DAW machine.

The presentation included a pre-recorded video demonstration, and a live demo setup was available for participants to try during the coffee break which followed. The demonstrated code is available on GitHub under the MIT license, which permits use in closed-source commercial projects, and everyone is invited to experiment with it for themselves.

Modifying existing plug-ins built with JUCE is a fairly simple process with just a few steps

• For the server side, the DSP parts of the code are isolated and wrapped as an instance of a new DSPServer class, which contains generic code for accepting incoming network connections, performing per-buffer DSP operations repeatedly, and gracefully shutting down connections. Using the JUCE Projucer, the resulting project can be prepared for building on Linux, Windows, and Macintosh platforms as a command-line application.
• For the plug-in itself, the existing PluginProcessor-derived class receives a new DSPClient member, and its processBlock() function is modified to allow the option either run locally as usual, or remotely by delegating to the DSPClient's processBlock() function:

• Appropriate controls must be added to the plug-in GUI to allow user entry of the remote server's IP address and port, and to switch between local and remote DSP operation.
• A few other minor changes may also be needed on the plug-in side, to facilitate serialization of parameter updates across the network connection, and to ensure that there are no noticeable changes in the plug-in's operation as it is switched between local to remote DSP modes.

The demo code is deliberately simple, to avoid obscuring the basic principles. Considerable refinement will most likely be needed to bring the implementation up to commercial expectations for robustness and ease-of-use.