In simple terms, DAW software, or any computer program, is a series of instructions that are executed sequentially by a central processing unit (CPU). Many DAW programs already incorporate multi-threading into their code. Here’s how it affects Cakewalk’s SONAR 3.1. Thanks to Ron Kuper of Cakewalk for this explanation.
A program that employs threads, or is multi-threaded, takes a sequential series of instructions and replicates it. Rather than having one sequence of instructions for all tasks that need to be done by the application, a multi-threaded program uses many sequences of instructions, one per thread. It’s like having many different little sub-programs, all running simultaneously, or in parallel.
Obviously on a single-processor computer these threads don’t really run simultaneously. The computer’s CPU can only perform one instruction at a time. But the operating system is able to provide the illusion that multiple threads are executing in parallel. It does this through a procedure known as scheduling.
In the Windows operating system the scheduler allows multiple threads to run in orderly fashion, one at a time, by carefully selecting which one should run next and then limiting how much time it gets before moving on to the next one. This scheduling mechanism allows applications to set priorities for each thread, to make sure that threads which involve user interactions remain responsive, and to allow threads to relinquish their “time slice” if they have nothing left to do.
Multi-threading with multiple CPUs: Multiprocessing
Multi-threading in Windows really starts to show its power on multiprocessor systems. The Windows scheduler detects the presence of multiple CPUs, and allows more than one thread to run – truly in parallel – by assigning one thread to one CPU and another thread to the other. Note that a Windows application must be written with multi-threading code and multiprocessor support in order to benefit from multiple CPUs.
Even on a multiprocessor system the weakest link in any application is the thread that carries the highest CPU burden. For example, prior to version 3.1, SONAR performed all audio mixing and DSP on the same single thread. This meant that you could create a project with a single solitary audio track, and then load this track with audio effects to the point where the project won’t play – not on a single processor system, or a quad processor system! This is because one CPU would be struggling to do all the mixing and DSP while the other CPUs would be sitting idle.
In other words, the division of labor between threads must be carefully chosen in order to get the maximum benefit from multiple CPUs. Ideally the most CPU-intensive sections of code would be multi-threaded. In the case of SONAR, it meant that the code that does mixing and runs plug-ins and soft synths, needed to be designed in a way to be run on multiple threads.
Mixing, DSP and Multi-threading
The SONAR 3.1 audio engine contains a component called a basic “audio processing unit” upon which tracks and buses are built. So the logical progression in SONAR 3.1 was to allow the processing of each of these audio processing units to be performed on different CPUs.
An audio processing unit in SONAR 3.1 can process either a project track, a project bus, or a software synthesizer. Therefore, for example, a project with 8 tracks, 4 buses and 4 synths uses 16 audio processing units. Along with the existing set of threads already created for the user interface, disk access and MIDI functions, SONAR 3.1 will create one mixing/DSP thread for each CPU on the system. During audio streaming, the SONAR audio engine executive constantly builds a first-in, first-out task list, with each task corresponding one audio processing unit. At the same time, in parallel, each mixing/DSP thread removes items from this task list until all tasks are complete and the list is empty.
This design is analogous to a construction site where the job manager has a checklist of jobs to be done. Some jobs must be done before others, and the manager knows how to order them. Workers come to the manager one at a time and receive a task to do. When a worker finishes a task he comes back to the manager to get another. When the task list is empty everyone can go home!
The benefit of this design is that the program and the CPU are constantly self-adjusting to meet the workload of the project. Most real-world music projects have effects spread out among all tracks and buses, and have several synth instances. This means that the mixing/DSP workload naturally spreads out across all available processors. By contrast, imagine a design where even-numbered tracks were arbitrarily assigned to one processor and odd-numbered tracks to the other. Such a design would not suitably divide the work done by buses and software synthesizers.