Why don't Daw's Allow Over 100-200ms latency to increase CPU performance?

[Touch The Universe]

I find it quite curious why nearly all Daw's have the maximum latency you can set around 100ms. It's crazy. If I'm not automating anything or recording Midi, wouldn't it be a good idea to allow an increase in latency so we can add more stuff to our tracks without having to bounce or freeze. The Daw's I have in mind are Studio One with a maximum of 100ms using windows audio, and Fl Studio with a maximum of 179ms. Orion for example has up to 479ms and I can easily fit twice as much into a track without encountering any issues.

This especially makes sense with Studio One since it usually heavy on the cpu anyways. So why not in increase the latency. We are talking about performance increases of up to 200 percent on the same machine. You would have to have a system with much more powerful specs to get such an increase in performace.. It just doesn't make sense to me

[BertKoor]

Increasing the buffer size with a latency larger than 0.1s has only marginal effects on the performance, and I'll demonstrate why.

Assuming the sampling rate is 48kHz... And also assume that with a buffer size of 1 sample the DAW is completely busy with overhead processing and cannot service any plugins. You'd have a latency of 0.02 ms and the buffer is processed 48.000 times per second and CPU usage for overhead is 100%.

Now set the buffer size 8x larger to 8 samples. Then the latency is only 0.17ms and the DAW has to process the buffer 6000 times per second. Now the CPU usage without any plugins is brought down to 12.5%.

Set the buffer 8x larger again to 64 samples. Then latency is 1.3ms and the DAW processes the buffer 750 times per second. Now CPU usage for just the overhead is down to 1.5%, leaving 98.5% of CPU power available for plugins.

Set the buffer 8x larger again to 512 samples. Then latency is 10.6ms and buffer processing is done only 94 times per second and overhead processing costs just 0.195%, leaving 99.8% available to the plugins. This step you gained 1.3% of the CPU power.

Set the buffer 8x larger again to 4096 samples, giving a whopping latency of 85ms. Buffer processing is done only 11.7 times per second, costing 0.02ms each which is 0.024% so 99.976% of CPU power is available for plugins. You gained a meagre 0.17%.

Set the buffer 8x larger again to 32768 samples, giving your desired latency of 683ms. Buffer processing is done only three times each two seconds leaving 99.997% CPU power to the plugins. You have gained a really marginal 0.021%. How many extra instances of Dune can your project now handle?


The real issue at hand is the poor performance of StudioOne. Put it on the torture bench next to other DAWs and it will lose by a big margin. This is the problem that needs to be tackled! Extra latency won't give you anything significant in return.

[Touch The Universe]

Wow. Thanks. I think I understand it a lot better now. It is really odd though when you say the performance increases only marginally by increasing the buffer. This is not at all my experience. Actually, I just did a test and it confirms what you said. It's really weird since I can remember dozens of times that when I increase the buffer from say 100ms to 400ms, any crackles disapear and I'm able to playback the song without issues, so I figured cpu dropped a lot. I guess it was just a difference of a few percent to take me above the threshold of crackling. Thanks a lot for your explanation

[bungle]

Some DAW/Hosts are just terrible at low buffers, The latest releases of Maschine jump out here too, they are so inefficient that it beggars belief, one project that works on an older release wonot work without glitches in newer releases, supports answer "Your i7 is a bit out of date" hahaha

[camsr]

The buffer size can help with disk access, it's better to load a larger portion of audio less frequently. This doesn't apply to holding audio in RAM.

[Image-Line]

Interesting conversation, and one we often have with our customers in conjunction with system vs DAW CPU load...two issues to consider:

Time-scales

The audio buffer size, 1 ~ 50 ms. While the operating systems CPU meter may show 30% utilization, over the last 1000 ms (system meters are around 1 sec integration), there may have been multiple occasions during that period where real-time audio processing experienced interruptions. Why? If real-time audio 'Mixer threads' (packages of work for the CPU), have to wait on other threads to finish, because they can't be multi-threaded (processed at the same time), the DAW may experience audio underruns, or at least very high internal CPU meter readings. At the same time, the OS may report low overall and or individual CPU utilization. The CPU could have done a lot more work than it did, if it had something else to do at the same time. The reality for audio processing is the CPU must often wait for program and system related tasks to complete before it can continue, and so, may struggle to keep up with the very high demands of realtime audio output (generating 44100 samples per second, on an ongoing basis, without an interruption of a single sample, 0.02 ms). Just why the CPU must 'wait' is all to do with logic:

The logic of audio processing

There are long lists of tasks that must be processed in sequence, and this means logically can't be simultaneously multithreaded. For example: Plugins must wait for instructions from the Piano roll and Playlist before they make sound. Effects must wait for the audio stream from upstream instrument plugins before they can process it. Further, it's not possible to parallel-process (multithread) instruments and FX that are on the same Mixer channel (their audio is mixed together), or even in the same Mixer routing pipe-line (when one Mixer track is linked to another and another, even FX processing has an order from top to bottom in the FX stack). Then, the Master Mixer track must wait for every instrument > mixer track > effect to be processed before it can process the audio through the Master effects. Logically, there is a lot of waiting, that is a natural and unavoidable fact of DAW music processing.

Think of a production line. This means the CPU may not be particularly busy, using all its cores and processing slots, yet it runs out of time to fill that tiny 5 ms audio-buffer because there was a lot of waiting for things that needed to be processed in sequence. It should be clear that fast processing is very important and this is not the same thing as multi-core processing. The best CPU is one that has enough cores to spread the work around AND can do the most work on a single core during each buffer time-slice. Which leads to our TIP: When comparing CPUs, look for the fastest single-core performance scores in a package with at least 4 physical cores. Most CPU benchmarks list single core performance. For example, the CPU Benchmark website lists the single core scores.

[nonnaci]

Also, many algorithms such as FFT make better use of memory caching or have overall lower flop count when handed larger block sizes.

[dougb256]

Logic allows up to 1024 ms of buffer, which is where I set it when I am mixing. I didn't realize that other DAWs didn't.

EDIT: Wrong. Logic allows up to 1024 samples in the buffer. Oops! I would delete this whole reply if I could just figure out how to do it.

[ghettosynth]

Also, many algorithms such as FFT make better use of memory caching or have overall lower flop count when handed larger block sizes.

Right, which is why the explanation above doesn't tell the entire story. It's not only about how much CPU remains to process plugins, but, also how efficient those plugins are with that remaining CPU.