Question about multicore processing in relation to routing

Help, Support & Bugs
#1

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…

#2

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
#4

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?

#6

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?

#7

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

#8

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 …

#9

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

#10

What is your OS?

#11

macos 10.13.6

#12

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

But I will make test on Win10

1 Like
#13

x

1 Like
#14

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.

#15

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.

#16

I have a silly question

Have you enabled all the cores in preferences?

#17

yes, all 8

#18

Image 3 Image 4

Maybe you can changes some parameters

#19

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
#20

Maybe some “hungry” monothreaded plugins can cause problem?

#21

Thanks. I will make some tests with that song project once I have time again, and posts results here.

#22

Hi again,

so here I have another project which makes me wonder why the cpu is not nicely used, but instead the Activity monitor shows a 180-220% of 400% at maximum, while the song already starts to stutter at 8ms / 44,1kHz. I have the impression that this did not happen in older Renoise versions, but I cannot load the project into the old version anymore for a comparison, so I cannot prove that.

The song has two summing sends, bass+drums and the remaining instruments. Before those two sends, there are “ducking” summing sends, to which an amount of individual tracks is sent. These ducking sends route then into the final two ones above. Sadly almost the whole song, the output stutters.

I guess due the lots of send tracks, the second mode is then used?

Could it be a problem that sends route into other sends, performance wise?

Lots of Zebra 2 instances (one single 32 bit fx plugin):
grafik

Still the activitity monitor only shows:
grafik

After deleting those two summing sends, the stuttering almost goes away, but still the usage cpu meters are weird, far away from 100% / 400%:
grafik

Activitity monitor shows:
grafik

So what still puzzles me:

  • Why I can’t remember those stutterings in older Renoise versions? Am I old already?
  • How can I practically change the project, so it uses most of the cpu? (Maybe using sidechain + that melda plugin?)
  • Could this be cpu spikes / denormal numbers related?
  • Is there a way to determine cpu spikes with Renoise?

My hardware did not change since years, I also did not flash any bioses (I don’t want any intel cpu degradation/security patches). Also I still use macos 10.13.6… I don’t have any of such problems in Bitwig, even with a “shitload” of plugins at 8ms. Please, any idea?

1 Like