Audio callback and multiple threads

Question

Given that real time inputs(low latency, say 96000khz SR and 128 "byte"(generally are these actually bytes or frames?) is about 1ms to process the input) must be processed quickly, I can't see how multiple threads can be used.

An audio engine only has one callback from the hardware to fill the output buffer!? The callback surely doesn't spawn another thread because this could take quite a bit of time. Even if it does, it can't guarantee the thread will be finished processing in time.

The best I can tell is that the way audio is done requires the use of a single thread for all audio processing except that which can be pre-computed.

Are multiple threads in DAWS actually be used for doing simultaneous processing of the callback buffer? If so, how is this achieved without wasting a ton of cycles just on the threading management part of the code?

Are "multi-threaded" DAWS actually using multiple threads for audio processing of real time inputs or are they using one thread and the others for doing various other things(graphics, UI, etc...)?

By multi-threading I mean running them on different cores of course.

Answer 1

Yes, audio software, be it a DAW or a live mixing console, do use multithreading and multicore functionality.

Example 1 : Pyramix

MassCore technology “hides” one or more cores in a multiple CPU computer and then creates a “pipe” directly between the software and those hidden cores to essentially create an Intel-powered DSP based system.

Example 2 : Studer

STUDER discovered a unique way of isolating several of the CPU cores leveraging the Linux OS and stopping these cores from being interrupted. One core is left to run the desk communications and housekeeping whilst the rest of the cores concentrate on audio processing for the highest channel count and without the need for buffering and the consequential audio latency.

Example 3 : Reaper

Outstanding multiprocessing capabilities for systems with 2-16 (or more) cores.

These are only examples of explicit mentions I could find quickly. But I would think that most of current DAW software do use multicore capabilities.

I cannot discuss issues related to thread management in programming audio tools, but to answer some of the points you mention :

Even if starting a thread is relatively costly, you don't have to launch them every second. You can launch several threads (on several cores) at application startup and keep them alive to use them as needed.

Many threads in this context don't have to deal with data race/mutexes issues. Think for example of a thread computing plugins effects on a single track/channel. I would think this lightens the thread management issues.

Answer 2

Note that audio synthesis algorithms can be inherently highly parallel. You have several buses that can be split into independent sets, such that no audio inputs of one class correlate (i.e. have data dependencies) with others. You render a single buffer and, when no delay is applied immediately, this buffer can be rendered in a embarassingly parallel manner, first N/2 samples rendered independently of the remaining N/2. You have a GUI thread, you have a rendering thread, you only need to assign proper priorities to them. You have a pool of threads each one sleeping until there's more data to process and generate.