At least some established DAWs, and more specifically, their associated plug-in interface APIs, were not designed for distributed processing. Optimizing DAWs for distributed processing will require architectural changes, a few of which are suggested below. Ideally, such changes should be done in support of agreed-upon standards.
The architecture of most DAWs exacerbates the latency problem. Because DAWs have been designed around the assumption that plug-in instances share the same CPU, they provide only one basic callback to each, which is called processBlock in JUCE (more generically called the "render function").
This function is called just once per buffer-interval, and both provides the plug-in with the necessary input data, and expects to receive the corresponding output data. The plug-in DSP code basically hogs the CPU between the time that it is called, and the time it completes processing the current buffer and returns.This makes perfect sense for local DSP execution, because the plug-in will be using the CPU for the entire time. For remote or hardware-accelerated execution, it is wasteful, because while the render code must wait for the accelerator hardware to complete its work, even though it could, and ideally should, relinquish the CPU during this time.
A DAW which "knows about" hardware DSP acceleration could potentially operate more efficiently. It would still call each plug-in's render function once for each buffer, to provide that buffer's corresponding input data, but if there were some mechanism whereby the plug-in could tell the DAW where to expect the output data to come from, it could, in theory, return immediately. The DAW could then use an operating system service function such as the POSIX select function (or any broadly similar asynchronous I/O mechanism), to efficiently monitor all pending DSP operations simultaneously, incurring virtually zero CPU overhead.
The greatest benefits of distributed processing will only be realized with DAWs that know about standardized communication protocols for
The first two of these issues are obviously closely connected, but if we admit the possibility that existing DSP module-instances could be relocated from one server to another (for load balancing), all three issues become inextricably connected.
It is also conceivable that DAWs could be designed to accept server-side monitor-mix signals which are not clock-synchronized to its own primary mix, but this is probably unnecessary. Server-side mixes can be distributed (e.g. to performers' headphones) using traditional audio routing hardware in a typical recording studio setup.