Maybe it’s not strictly a bug - but it seems that the 8 threads are not being used properly so I put it here.
Here’s an image to illustrate what I mean
Although the new version can handle slightly more heavy loads than the last version *2.7.2 - it seems that the program reports high cpu usage while it still is only scratching the surface of what the CPU is capable of.
I can understand that there may some issues to do with real-time’ness and I understand that SMT and SMP aren’t simply multiplying performance, but then if coded properly I expected much more complete use of the CPU especially with the whole audio-plugin system…
Is it possible that increasing the buffers would help?
I’m in max performance mode and using throttlestop to prevent low-power states so am sure it’s not a configuration thing in terms of the system. But perhaps there’s something else I’m doing wrong - are others experiencing anything similar?
Also notice that Hyperthreading is not being used at all… This module contains 20+ plugins so am confident it should be able to load-balance better than the reported ~20% usage I’m getting…
Thanks in advance for any feedback/advice!
Oh, and forgot to point out that I do start to get stuttering at this stage even though the CPU should handle a lot more load.
Renoise can not split up the work balance of “all loaded plugins” to all available cores. It splits up tracks (independent signal streams) to cores (threads): Signal streams which do not depend on each others and thus CAN be calculated in parallel.
So the main distributable parts of the song are not plugins or DSP units or instruments, but tracks. Then also shitload of other things come into the game like plugins which do not support running in parallel (all synthedit plugins and a few others). How tracks are routed/connected (send tracks + groups) within the song, and how much CPU the individual tracks do use. If you for example have one track which eats up 90% of the CPU, while the others only use 10%, then a system with two cores can not double the performance.
In a 4 core hyperthreading setup (8 virtual CPUs), the system will also not make use of all 8 cores at relatively low CPU usages, but uses the real 4 cores as long as this performs better in overall, before enabling, using all 8 cores.
It’s hard to guess what exactly the “problem” is in your scenario. But yay, there’s always room for improvements, so if you want to share the song or other songs where you hope or think Renoise could do better and could give us more details, we could have a look at this.
Perhaps you could do some kind of analysis pass where the program measures which audiopluginservers use how much cpu (both peak usage and overall) and then makes a calculated guess as to which ones could be assigned which affinities?
That would provide a better usage of the cores when running under heavy duties… I’ve gone and played around with the affinities myself and it definitely helps to put heavy usage servers onto a core of their own, while putting all the low usage servers onto a seperate core of their own…
Setting CPU affinity does not do anything good according to our experiences. The CPUs do not only run Renoise, but the whole operating system, so the operating system can do a much better job scheduling the work load to CPUs than we could do. All we do is offering the operating system X threads for scheduling (the “number of Audio CPU’s” in Renoises Audio preferences).
We also do measure the CPU usage of the separate distributable units in runtime already, and rearrange them to the separate threads on the fly accordingly.
The real problem (bottleneck) is that the workload often !can! not be spread evenly, because of the dependencies and structure of the song. The more cores and less independent tracks you have, the worse it gets.
But once again, example songs or something more concrete is appropriated. I don’t think we’ll solve this problem in theory here. If you don’t mind I’ll move this topic to the general Help and support forum.
Okay, that’s good to know… I had some success moving the affinities of individual plugin servers but thanks for helping me understand more about the internals of renoise… Just from experience, the OS isn’t an issue generally and hardly takes up any resources while doing something foreground (like a game, photoshop or renoise)…
Yeah you’re right to move this thread - hardly a bug report haha - thanks for the feedback and information I’ll try to optimise the process in the way I lay out the tracks/plugins…
maybe it would be nice to post some multicore guidlines for renoise like
if you want to save cpu do not use the same send channel for all instruments etc,
maybe it exists but i missed it
is there a way to trace which channels go to which core ? this could help to move the channels around in a way so the cores are used more evenly. or am i thinking about this to simplistic ?
i am very interested in how renoises usage on cpu works as well.
i have a bit older i5 750 quad core.
now, i have this project that sometimes (ill explain later why “sometimes”) crackles up at one part to the point of renoise stopping it due to cpu overload, and i look at the system explorer performance tab while this is happening, total cpu usage doesnt go over 30% while max core usage by the most used core is 50%. but still, the renoise says it used 90%+ and stops the crackled audio.
and this “sometimes” part, when i load and play the song for the first time it breaks up to the point of cpu stopping it mentioned above, but then its like it “loaded” something since second playing is totally smooth. why is this? it uses same plugins and does same calculations as before in real time.
this can happen if you’re using sampler plugins, like kontakt libraries, EWQL, etc.
those tend to load a couple of samples upon song load, but the rest is read “on the fly” and stored in RAM for later use, once it got requested.
so the crackles might occur because your harddrive fails to deliver the required throughput to load the sample in realtime once the respective moment in your song has been reached.
this is actually more like a plugin than a renoise issue, if my assumption is correct.
It’s a new Sandybridge i7 right? (if so, nice! I’m jealous )
I’m about 99% sure they’re the ones that have two redundant cores, the idea is that when the two currently most used cores heat up from turbo boost (or just being generally thrashed) the cpu can automatically switch to cooler idle cores on demand rather than slowing down while still under demand.
Someone feel free to correct me, I couldn’t find the article, but it was the recent topic of conversation at work with a guy who’d recently upgraded to a sandybridge machine.
why would a plugin loading its sample from a hard drive make renoise spike to 100% cpu usage and make it kill audio?
and why would renoise show 100% cpu usage while cpu monitoring tools say total cpu usage of everything running on my system is like 30% with not a single core over 50% usage?
and this, might i add, is even a much smaller real cpu usage by renoise since my system uses like 9% cpu when idle i guess on system needs. meaning renoise can use what, only 20% of my cpu power before choking?
this would make sense if at least one core was used to 100% before crackling. however, the most used core (in my case at least) is only 40% used and sound/renoise breaks due to cpu overload.
I’ve also been running into this, and in a more general sense am curious how Renoise arrives at its processor usage numbers.
I’ve got a very short looped couple patterns that I tested with a single Omnisphere instance and here’s what was reported:
Renoise says it’s between 35-45% CPU usage.
Task manager says the renoise process is using between 2-3%
Total CPU usage in task manager is reported between 3-7%
I’ve got an i7 920 with 9gb of ram running in Win7 64 bit. During this test memory usage stayed consistent at about 450mb.
Fortunately this hasn’t caused any actual issues, but I’d be curious to find out more before Renoise starts cutting out on me while task manager still insists none of the cores are being pushed anywhere near 100%. From what I can tell it seems most likely that it’s just misreporting the usage percent?
If others here have Omnisphere I’d be happy to post my test track…without using it I haven’t had much luck getting Renoise to use enough CPU cycles to get any sort of meaningful numbers.
You can’t compare Renoise its cpu usage with the taskmanager because Renoise is displaying a percentage related to the use of the audiothread that it (got) assigned for the jobs and not the amount of CPU time that Renoise uses in the system. But i’m only repeating here what has been mentioned here in the past on this board. but in any case:Forget about the figures in the taskmanager, they lead you nowhere in this type of analysis.
Fair enough, I’m just concerned that I’m going to have Renoise start killing my audio when according to other sources it’s only using, say, 30% of one core. Still, it hasn’t happened yet so at this point I was more curious as to how Renoise is arriving at its usage number (being a programmer myself it seems like an interesting problem to solve).
So having done a few more tests it appears that it’s probably (at least something similar to) the highest single-core load that’s being reported. I tried 1 vs 4 instances of Omnisphere on 4 different tracks and it made almost no difference in the reported processor usage %. So that’s good news for me, I at least shouldn’t have to worry about Renoise dying if I have more than one Omnisphere instance running.
I’ve encountered similar problems on my latest studio computer (Intel Core i7 3930K / 32GB with RME Fireface UCX soundcard): crackles, hiccups and generally not the type of behavior I was expecting. It’s running Windows 8 though so that might be a problem on itself. I’ve also noticed Renoise (like any other audio program) has trouble handling 32 and 64 bit VSTs in the same environment. When you sandbox everything, that seems to help although I recently had a problem where Renoise all of a sudden wouldn’t initialize Kontakt’s 64-bit dll.
I’ve noticed that solely running 64-bit VSTs helps. It’s ironic to be able to run 12 instances of a 64-bit Guitar Rig and at the same time have a minor Waves VST in 32-bit stall the entire program.
But yeah… I do hope that with a new release of Renoise, things will start behaving a little more stable. I’d hate to be forced to switch to a different sequencer because of this. Although well… the latest Cubase has similar problems, Ableton still needs to release its 9th installment and well… I don’t feel like learning yet another package.
Bridging 32-bit to 64-bit programs always costs more effort for CPU’s, i don’t know how much more efficient this can be made.
Obviously:32-bit applications already need to be transcoded by the operating system, then the bridge software has to transcode the result to 64-bit and send this to the 64-bit host and to do this sample precise, i suspect this costs quite a lot or where most loss of cpu power goes into.
Now if somehow Renoise 32-bit could Rewire with Renoise 64-bit, i suspect this could relieve the CPU from some stress because in that case, only the audio streams have to be transcoded somehow, because the native Renoise versions don’t need to bridge anything if you stick to running 32-bit plugins in the 32-bit Renoise version and the 64-bit plugins in the 64-bit Renoise.
I don’t know if this latter theory can be tested somehow with e.g. Reaper using ReaRoute, because i don’t know if reaper supports cross transcoding 32-bit and 64-bit audio streams. Reaper does attempt to support 32-bit and 64-bit Rewire in the 64-bit host.
What i aim for here is trying to run Renoise 32-bit and 64-bit and try to ReaRoute both into Reaper 64-bit.
I’ll try to optimise the process in the way I lay out the tracks/plugins… 
)