Question about multicore processing in relation to routing

Hi,

if my song uses a routing where almost all tracks sum into a specific send track by some amount, does this mean that all those tracks will be processed on the same cpu core then? I have some weird stuttering sometimes in a song, and wonder how I could “cpu-optimize” the project…

My understanding is that the effects on a send track all process a single stream of audio regardless of how many tracks were mixed into that stream. I would think moving effects off of the tracks and into a group or send track would be a way to reduce CPU load.

2 Likes

@ffx

Make a flow chart.

Optimize that.

sound A → effect A → sum effect C
sound B → effect B → sum effect C

is not as fast as

sound A → effect A → effect C
sound B → effect B → effect D

but it takes more CPU because effect D is added.

Throw away all sends!

incrementing latency is all it takes.

1 Like

Same trouble with the sound. I have a not-so-good pc and maybe smth is taking a lot of CPU? I have computer monitoring software and some other programs open and running. And it has access to all data and processes.
Could the problem somehow be related to this?

When you use a lot of plugins, samples and/or effects, then yes, it is adviced to get high-end gear or close all other applications on a slower PC.

Increasing the sound card latency in the Renoise options may also help.

Well I often use processing busses. So I need to sum a lot of tracks into often only two busses/sends.

The last song I posted actually maxes out at 100% renoise cpu meter, while the activity monitor clearly only shows 200%, so at least 2 cores are not used at all! Damn…

I have two final busses, “drum + bass” and “instruments”. Is that the reason? Was there any info about multicore processing in the manual? @taktik Do you maybe have any tips for me here?

Interesting problem
When I’m 45% on renoise,I’m 25% on system

Via ressource monitor (Win10),I can see that renoise use the 4 cores on my system
Renoise is well multitreaded

Yeah, but how it decides which plugin is using what core, that is dependent on the routing. I hope it’s not that summing sends will cause all sending tracks to be processed on the same core. Because then the core is pretty quickly maxed out and it will cause drop outs.

Why is that with the sends? Or is it not? Master does not require that either …

Ok,I see what do you mean

I will make the test with heavy and lite plugins

But In my advice,renoise is well optimized and use a good multithreading architecture

What is your OS?

macos 10.13.6

I don’t know this “BSD” based OS…

But I will make test on Win10

1 Like

x

1 Like

Hm that’s weird, since in my project, only 2 of 4 cores are utilized. Are you using plugins with explicit multicore support, e.g. uhe plugins?

For the idle test, did you double click the stop button to flush all the audio buffers first? It should show more then a constant load, not jumping anymore.

I will make some tests myself this evening.

The point is, for the concept “bus processing”, you can’t put that on individual tracks, e.g. limiter, it’s about processing the summed signal.

The “Heavy FX” is “analog obsession Dynasaur”
Multitheading is not mentionned Here :

But monitoring cores use,and using only one instance of this VST,I can say it’s a multithreaded VST

From my point of view,“Internal routing process” doesn’t really impact performance
Realtime sample processing and VST(I)s have the biggest impact

Renoise “smartly” distibute threads.Routing has no impact on this distribution.

I have a silly question

Have you enabled all the cores in preferences?

yes, all 8

Image 3 Image 4

Maybe you can changes some parameters

The multi-CPU processing in Renoise has two modes internally:

One, where all signal paths are followed up to their end and processed asynchronously - including the send tracks which end up in the master track or some dedicated hardware outputs.

And the other one, where processing is done in two passes: first everything without the send tracks is processed asynchronously, then the send tracks are processed asynchronously.

The second mode is automatically selected when there are too many send connections. So using does not always degrade multi CPU performance.

1 Like

Maybe some “hungry” monothreaded plugins can cause problem?