Export only using one core

[syntonica]

I am exporting a completed track using Export Composition as Audio File and only one core of my CPU is being used. Is this as expected, or am I misconfigured?

Track is all audio with no vst instruments plus many effect plugins, if that makes a difference.

[pljones]

If there's a single signal path where there's no opportunity for parallelism, you're not going to get multiple threads / cores being used.

[syntonica]

Drat! But I would think with a dozen or more VSTs running, there'd be threads galore to assign to each core.

Oh well. Guess I will have to learn to be patient.

Thanks!

[pljones]

The problem is that the input to one depends on the output of another. You can't echo a signal until you know what that signal is. You can't filter that signal until... etc. And then you've situations where the echo will need to know what the previous signal was so it can correctly mix into the current signal -- you couldn't split that up without completely breaking the effect. If you can wire it in parallel, it can be processed in parallel. If you can only wire it in series, it can only be processed in series.

[syntonica]

I'm not sure how audio is processed under the hood, but isn't each track its own thread? Can't each track essentially be assigned to a different core? Since the bounce is not happening in real-time, any timing issues are little more fungible.

[dakkra]

I'm not sure how audio is processed under the hood, but isn't each track its own thread? Can't each track essentially be assigned to a different core? Since the bounce is not happening in real-time, any timing issues are little more fungible.

Sortof....

Audio processing works on buffers. Real-time audio processing, at least in the digital world, isn't really real-time. There's a buffer in there somewhere from 1ms to 4s in length. The larger the buffer, the more audio the processor can asses for computations. Thus, you need more then a single value, float or int, to process the sound (Commonly known as samples). For example, an equalizer processes harmonics. if you give the equalizer a single value, it's not going to know how to use it. But, if you give it a buffer of values, say several cycles, the equalizer can read the samples, translate into harmonic data, and then render out new samples based upon it's settings.

Now, in a final render, there should be as little hiccups as possible. Because audio works in buffers, not single samples, you can't process parallel audio without technically being inaccurate. I learned this while programming Sonic Candle, which generates a video built of FFT of the audio buffers. Because it needs a buffer to generate the transform, I can't split up the audio without having "jumps" in the video. So it has to be processed linearly.

Hope this helps,

Dakkra

[syntonica]

I get the whole buffer thing, but thanks.

I ended up switching the CPU from automatic (2 threads) up to the max--six threads, I believe. My export ran a little over 90% of processor power, but then the program ran miserably badly, otherwise. I switched back to the auto setting and will just wait it out.

[mutools]

Maybe you have a cpu that does hyperthreading. Also try a setting of 6 / 2 = 3 processor threads.

[fluffy_little_something]

How does Mulab determine the automatic setting? I remember it was 3 in my case even though my processor has independent 6 cores and no hyperthreading...

I have never exported a huge project. So, does Mulab do it perfectly regardless of high sampling rate and bit depth, oversampled VST hogs and everything? In other words, it may take half an hour, but the result is perfect no matter how weak my processor as such is? Unlike with live playing

[syntonica]

Here's my processor:

Processor Name: Intel Core i5 (I5-4278U)
Processor Speed: 2.6 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB

So, it does have Hyperthreading. I had set it 4 threads, not 6. I'll have to play around with the 4 to see how well it handles a huge load.

[pljones]

Total Number of Cores: 2

This is the critical number.

When you want to process data quickly, you do not want to "do a bit of this, put this task away, switch threads, do a bit of that, put that task away, switch threads... etc". You want to "do everything I can for this task".

So MuLab says "OK, you've got two cores, they may or may not have hyperthreading but that really doesn't help if I've got work to do, as I need 100% concentration". But it's nice: if it grabbed both your cores 100%, then your keyboard, mouse, windows, etc would stop working as there would be no CPU spare.

So if you've two cores, it will only grab one of them. You may well see no hyperthreading on that core, as that would show the core had some spare time to twiddle its thumbs, so to speak, and decided to get on with something else.

[syntonica]

Heh. I would hope some of those threads would have a higher priority than MuLab churning out my bad songs. And it seems that they do since setting it to 4 threads took about 90% of the CPU, leaving the remaining ten for boring stuff like key presses and mouse wiggles.

I really don't get why Hyperthreading is a thing since software already handles all that anyways. It seems more a hindrance than a help.

I just need to wait until I have a project that needs more than half the CPU. Maybe if I downloaded the demo for Diva and ran a few instances of it to see what happens.