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.

  • Can the implementation with DAW be done via circular buffer and two threads? Jan 2 '20 at 4:56

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.

  • But it's quite costly to keep those threads running constantly not doing anything. I mean, the problem is that one has to make sure a thread is on it's own core(else it is pointless, but this is usually easy to do) and that the thread is not interrupted. It just seems like a lot of "ifs" to get optimal performance, which, from what I've read, is only something like about 2.5x for 4. Have to look in to it more since I'm not well verse in the intricacies of multi threading. If one can just have worker threads always trying to do work and deal with any interrupted threads properly it might work. May 21 '18 at 22:39
  • @AbstractDissonance : I tried to answer to the question to know if DAWs use multithreading/multicore. If your question is how is it implemented in software, it's probably off-topic here as it is a general programming issue. That might be better answered on stackoverflow.com
    – audionuma
    May 22 '18 at 4:59

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.

  • 1
    It's not easy as you think. Task switching is costly along with scheduling. Depending on the audio path it may not be very effective. Most desktop cpu's have from 2 to 8 threads. The only thing I've seen that is somewhat effective is to use threads that spin but this burns cycles. Sleep cannot be used because it generates task switching and also causing scheduling problems. I've seen a paper that does some extensive testing and for 4 threads it shows it can only get a 2.5x increase but their are pitfalls. Remember that latency also comes in to play. I'm not saying it can't be done,just tricky Jun 14 '18 at 21:35
  • ... because even one drop out can be fatal. The more complex the code to deal with the threads increases the likely a drop out will occur much sooner than the idea case. Jun 14 '18 at 21:37
  • Sure they are not embarassingly parallel as a rule. Yet even a 2.5x gain can be essential, especially in such a highly realtime domain.
    – bipll
    Jun 14 '18 at 22:03
  • 1
    It depends. If the scheduler adds enough jitter so that there is a chance of drop outs then it is useless. The scheduler will become more unstable when the processing goes out, which is where the problem lies. For low usage cases it won't matter too much either way. Jun 15 '18 at 1:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.