Standard Aux/Bus objects consuming irrational high CPU

[Lykdraft]

Soooo. A while ago I was concerned about Radiums CPU use. I was wondering why that is. Conclusion was that the multithread scheduler wasn't the best, so we left off there.

But: Turns out that the CPU measurement on mixer-level comes in pretty handy now.

I discovered that the standart bus/aux modules, that should be nothing more than a pipe use up by far the most CPU in all of my projects. How can that be?

The Bus modules tower the actual reverb/delay etc plugins modules more than tenfold. Also the average per module consumes more CPU than one of the most calculation intense Reaktor Ensemble Effects there is.

Look at the picture, you can clearly see something is waaaaay off here...

[kmatheussen]

I've seen that the pipes often use lots of CPU too, and I've looked through the code if there is something wrong, but couldn't find anything. I think the reason for the high CPU usage is CPU cache misses. Since the sound objects that receives audio from many other sound objects reads a lot of memory, the number of cache misses will be higher. Modern CPUs are strange that way. The good news is that the audio engine in Radium can be optimized since currently all sound objects have their own audio buffers instead of reusing from a shared pool.

[Lykdraft]

Good news indeed. Because when I subtract those numbers (75% on average, when added up) I would (at least on paper) triple the CPU power available at the end of a production, which leaves way more room for mixing plugin. Which is a huge thing/number.

Numbers might not be 100% correct, because my average total now is 80%. But everything crackles and clicks like crazy. Render however is fine.

But no wonder that I max out all the time with barely any high CPU plugins involved.. :) Really looking forward to that optimization-fix.

[kmatheussen]

Oh, okay, I didn't know CPU usage was still a problem.

On Tue, Nov 1, 2016 at 11:02 PM, Lykdraft notifications@github.com wrote:

Good news indeed. Because when I substract theese numbers (75% on average, when added up) I would (at least on paper) triple the CPU power available at the end of a production. Which is a huge thing/number.

Numbers might not be 100% correct, because my average total now is 80%. But everything crackles and clicks like crazy. Render however is fine.

But no wonder that I max out all the time with barely any high CPU plugins involved.. :) Really looking forward to that optimization-fix.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/issues/727#issuecomment-257712398, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9pzfLKwxS1RX505JcpzCn5HLpi9Jlks5q57b9gaJpZM4Kmne2 .

[Lykdraft]

Sure is, because from the actual perspective it's now very likely that the AuxBusses taking away so much cycles that there isn't really a lot of headroom anymore.

If they could be deleted, I could check how much theese actually are really taking up from the whole project CPU average. But unfortunately they can't be deleted.

[Lykdraft]

Also keep in mind that I have a pretty solid Mac Pro 6-core running at 3.33 per core, which I barely manage to run to it's limits on Logic, DP or PT for example. Even with real CPU Hogs and VSTi Instruments involved. I can really throw a lot at it without even thinking of micro-managing or grouping stuff to save CPU cycles.

In this actual project I have 16 sample players running. 2-3 more for occasional crash,fx and stuff) No VSTi Instrument at all. This really isn't much. Not much plugins for processing, and a lot of them grouped to even micromanage CPU more. No CPU hog with exception of Reaktor (taking up 15%) and another one around the 10% mark. Everything else is pretty much 0-3 percent. And it's not a big, complicated project. (Also there is quite a number pizmidi processing stuff in there, which doesn't take up any CPU at all..)

The new CPU saver helps a lot in cases where I have VSTi instruments in some parts, or extensive fill-effects going on, but is obviously completely useless on the busses. And it really looks like that theese are the main reason Radium is crushing my system.

Heres a Birds Eye view. This little project brings down the whole system... There is really not much in there.. (I usually go nuts with plugins in Logic: Full processing chains, 4-6 plugins per channel, on around 30 to max. 40 channels..no problem at all. Still room for heavy CPU intense mastering chain in the same project... Still no problem.. :) So I know my system can handle that.)

[Lykdraft]

...this is now No. 1 on my list. Unfortunately I am hitting ceilings pretty early all the time with everything I am working on right now.

I am wondering if this can be worked around by using normal Pipes (or direct input to effect modules) than using the aux-buses... Will make a complete mess visually, but might be interesting to know.

[kmatheussen]

Okay, I'll look at it. Using normal pipes should make no difference. Buses are normal pipes, except that the connections are hidden in the mixer.

[Lykdraft]

Great, thanks a lot.

However regarding the normal pipes.. hmm... I usually also use normal pipes to group stuff together and there are often also quite a high number of connections (Like all drums and percussions go into one pipe for example..) And there I see no high CPU consumption at all... If that's the case, shouldn't I see a high CPU number in this case as well?

EDIT: I just made an extreme example and something must be off then... Two modules are sending to Aux1 Zita Reverb... More than 40 cable connections (with audio playing) are going "manually" into a group-pipe. Now compare the average CPU value. Take a look:

[kmatheussen]

Oh, that's shocking. Something is probably not right then. But that's a good thing, because I don't really think there is that much that can be done to improve cache misses.

On Thu, Nov 10, 2016 at 7:05 PM, Lykdraft notifications@github.com wrote:

Great, thanks a lot.

However regarding the normal pipes.. hmm... I usually also use normal pipes to group stuff together and there are often also quite a high number of connections (Like all drums and percussions go into one pipe for example..) And there I see no high CPU consumption at all... If that's the case, shouldn't I see a high CPU number in this case as well?

EDIT: I just made an extreme example and something must be off then... Two modules are sending to Aux1 Zita Reverb... More than 40 cable connections (with audio playing) are gong "manually" into a group-pipe. Now compare the average CPU value. Take a look:

[image: __users_luetze_music_radium_radium_projects_vps_phalanx_full_setup_onerad] https://cloud.githubusercontent.com/assets/18437561/20188251/28e81d74-a778-11e6-9361-47145f49ad78.jpg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/issues/727#issuecomment-259762665, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9pwlBfLkESVGBJGT09zCaDB6G1y-Xks5q81zVgaJpZM4Kmne2 .

[kmatheussen]

Let's hope it's not just a measurement error...

On Thu, Nov 10, 2016 at 7:18 PM, Kjetil Matheussen <k.s.matheussen@gmail.com

wrote:

Oh, that's shocking. Something is probably not right then. But that's a good thing, because I don't really think there is that much that can be done to improve cache misses.

On Thu, Nov 10, 2016 at 7:05 PM, Lykdraft notifications@github.com wrote:

Great, thanks a lot.

However regarding the normal pipes.. hmm... I usually also use normal pipes to group stuff together and there are often also quite a high number of connections (Like all drums and percussions go into one pipe for example..) And there I see no high CPU consumption at all... If that's the case, shouldn't I see a high CPU number in this case as well?

EDIT: I just made an extreme example and something must be off then... Two modules are sending to Aux1 Zita Reverb... More than 40 cable connections (with audio playing) are gong "manually" into a group-pipe. Now compare the average CPU value. Take a look:

[image: __users_luetze_music_radium_radium_projects_vps_phalanx_full_setup_onerad] https://cloud.githubusercontent.com/assets/18437561/20188251/28e81d74-a778-11e6-9361-47145f49ad78.jpg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/issues/727#issuecomment-259762665, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9pwlBfLkESVGBJGT09zCaDB6G1y-Xks5q81zVgaJpZM4Kmne2 .

[Lykdraft]

Yeah, let's hope, but would that even make sense? (If both are just pipes, then both should measure the same way, both right, or both wrong...no?)

[Lykdraft]

Another test, I have the system CPU on here as well:

I enable two sends only, one to Aux1 and one to Aux 2.

• Average CPU goes up from 29% to 38%.
• On the system, Radium goes up from 244% to 264%, (takes a while for this number to catch up...)

Maybe this helps. I just don't know if this 20% jump on the general system is a lot or not. But I think it is. (When 100% is one full core, then a 20% is quite a number. If it's something else, then probably not.)

[Lykdraft]

Another final quick info:

When I start an empty new song and I use only one VSTi and send to Aux 1 and 2, I get no CPU on the Aux modules at all... (they stay at zero, sometimes 1 on average)

So weirdly it seems that there is a correlation between the general amount of modules present in the project and the aux modules CPU consumption per enabled send.

Or in other words: The aux modules CPU are somehow using more CPU per enabled send, the more modules are present in the mix... Which would explain that I only noticed the high CPU usage always at pretty late stages in my projects.

(When you multiply this with 5 aux sends and consider the possibility that multiple modules send to these five aux-busses, then we might come close to those pretty huge CPU numbers on all 5 aux-pipes combined. Hope that helps...)

[kmatheussen]

Seems like this might have started to happen when adding latency compensation. The bus connections can't just be turned on and off when it's used and not used, because it would screw up the content of the latency compensation buffers. Hopefully it's not too hard to fix.

[Lykdraft]

Hmm... Okay, I got my fingers crossed.

If everything fails, maybe an option to turn off latency compensation completely wouldn't be a bad thing. I'd rather work without it, then not to be able to work on further at all. (If this is indeed somehow related to Latency compensation.)

When rendering the final song, one could try to re-enable it. Radium still should be able to render cleanly, even when playback is not possible anymore at all due to way too high CPU levels, right? Should just render very slow then.

(BTW: I also recall now that some major DAWs had problems with compensating latency on AUX busses as well for a very long time. Some still don't do it on Aux-Busses. Don't know, maybe this is somehow related?)

[kmatheussen]

I'm adding an option to turn off using unused buses now. The only bad thing about this is that you shouldn't automate bus levels or bus on/off parameters.

Regarding latency compensation for buses, I guess this could be a common problem. I know that at least Ardour doesn't compensate latency on the buses.

On Fri, Nov 11, 2016 at 1:17 PM, Lykdraft notifications@github.com wrote:

Hmm... Okay, I got my fingers crossed.

If everything fails, maybe an option to turn off latency compensation completely wouldn't be a bad thing. I'd rather work without it, then not to be able to work on further at all. (If this is indeed somehow related to Latency compensation.)

When rendering the final song, one could try to re-enable it. Radium still should be able to render cleanly, even when playback is not possible anymore at all due to way too high CPU levels, right? Should just render very slow then.

(BTW: I also recall now that some major DAWs had problems with compensating latency on AUX busses as well for a very long time. Some still don't do it on Aux-Busses. Don't know, maybe this is somehow related?)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/issues/727#issuecomment-259945655, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9p0_z5k0yN5O4If35rs-sdeUJlcS4ks5q9FzHgaJpZM4Kmne2 .

[kmatheussen]

Sorry, I meant an option to turn off using unused bus connections.

On Fri, Nov 11, 2016 at 1:23 PM, Kjetil Matheussen <k.s.matheussen@gmail.com

wrote:

I'm adding an option to turn off using unused buses now. The only bad thing about this is that you shouldn't automate bus levels or bus on/off parameters.

Regarding latency compensation for buses, I guess this could be a common problem. I know that at least Ardour doesn't compensate latency on the buses.

On Fri, Nov 11, 2016 at 1:17 PM, Lykdraft notifications@github.com wrote:

Hmm... Okay, I got my fingers crossed.

If everything fails, maybe an option to turn off latency compensation completely wouldn't be a bad thing. I'd rather work without it, then not to be able to work on further at all. (If this is indeed somehow related to Latency compensation.)

When rendering the final song, one could try to re-enable it. Radium still should be able to render cleanly, even when playback is not possible anymore at all due to way too high CPU levels, right? Should just render very slow then.

(BTW: I also recall now that some major DAWs had problems with compensating latency on AUX busses as well for a very long time. Some still don't do it on Aux-Busses. Don't know, maybe this is somehow related?)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/issues/727#issuecomment-259945655, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9p0_z5k0yN5O4If35rs-sdeUJlcS4ks5q9FzHgaJpZM4Kmne2 .

[kmatheussen]

Also, you can automate bus levels, but you shouldn't send the value 0, because that could cause left-over sound from last time to suddenly appear when the bus level is enabled again. Have to think a little bit about how to fix that problem.

On Fri, Nov 11, 2016 at 1:24 PM, Kjetil Matheussen <k.s.matheussen@gmail.com

wrote:

Sorry, I meant an option to turn off using unused bus connections.

On Fri, Nov 11, 2016 at 1:23 PM, Kjetil Matheussen < k.s.matheussen@gmail.com> wrote:

I'm adding an option to turn off using unused buses now. The only bad thing about this is that you shouldn't automate bus levels or bus on/off parameters.

Regarding latency compensation for buses, I guess this could be a common problem. I know that at least Ardour doesn't compensate latency on the buses.

On Fri, Nov 11, 2016 at 1:17 PM, Lykdraft notifications@github.com wrote:

Hmm... Okay, I got my fingers crossed.

If everything fails, maybe an option to turn off latency compensation completely wouldn't be a bad thing. I'd rather work without it, then not to be able to work on further at all. (If this is indeed somehow related to Latency compensation.)

When rendering the final song, one could try to re-enable it. Radium still should be able to render cleanly, even when playback is not possible anymore at all due to way too high CPU levels, right? Should just render very slow then.

(BTW: I also recall now that some major DAWs had problems with compensating latency on AUX busses as well for a very long time. Some still don't do it on Aux-Busses. Don't know, maybe this is somehow related?)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/issues/727#issuecomment-259945655, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9p0_z5k0yN5O4If35rs-sdeUJlcS4ks5q9FzHgaJpZM4Kmne2 .

[Lykdraft]

Ah, I see. So I understand that "behind the curtains" every module is physically connected to all available Aux-Buses anyways as soon as they are added?

Also, there are several easy workarounds for bus automation, so that wouldn't be a problem. (i.e. like I do it most of the time: I use a Pipe as a placeholder and automate the volume of that pipe. That pipe has usually several Aux Destinations active, so I only have to automate one slider and not multiple ones... And still can finetune the send-levels afterward without having to fiddle with the automation itself.. pretty straightforward...)

[kmatheussen]

Yes, that's how it works. And before latency compensation was introduced, I think Radium just ignored connections where the volume was 0. But now, because there might be sound left in the latency compensation buffers, the sound from all connections must be mixed together to create the input sound to a sound object.

On Fri, Nov 11, 2016 at 1:29 PM, Lykdraft notifications@github.com wrote:

Ah, I see. So I understand that "behind the curtains" every module is physically connected to all available Aux-Buses anyways as soon as it is added?

Also, there are several easy workarounds for bus automation, so that wouldn't be a problem. (i.e. like I do it most of the time: I use a Pipe as placeholder and automate the volume of that pipe. That pipe has usually several Aux Destinations active, so I only have to automate one slider, and not multiple ones... And still can finetunte the send-levels afterwards without having to fiddle with the automation itself.. pretty straightforward...)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/radium/issues/727#issuecomment-259947599, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9pwO2BFH7icbaTyoXPUqTVi1lOiO-ks5q9F-xgaJpZM4Kmne2 .

[kmatheussen]

There is a new option in bottom of edit->preferences->audio you should enable. It seems to reduce CPU usage on the buses significantly even on small songs.

[Lykdraft]

Awesome, you're the best! ;)

[Lykdraft]

Finally: Yep, just checked it. I get a CPU reduction on average of around 20%. With auto suspend enabled as well, I even get around 30% or more.... Wow... That's indeed a difference... :)