I could have sworn a few of my songs weren’t as CPU heavy as they are now… and checking some VSTi cpu usage meters, it seems some of them just chew more up now… Just wondering if anyone else has noticed the same, or the opposite. That, and I like posting polls occasionally
I haven’t done extensive testing yet, but I probably will one of these nights. I seem to remember Taktik mentioning that things did get optimised even more though.
First impression is that they are lower, but I’ll have to compare them after work.
Directsound unfortunately… but I’m not using an asio emulator, just Renoise’s internal directsound support
Yes well this might be the culprit, the directsound buffering has been disabled for the recording function to work flawless.
The problem the use buffers in DirectSound seems to be a glitch in the architecture of the drivercontrol from Windows and many other application builders got trapped in this pitfall.
We experienced severe problems using the recording and line-in device with audio buffering enabled and this made the function actually very useless.
The only way out was disabling audiobuffering but this goes at the expense of CPU resource consumption.
So this is not really a particular VSTI problem, it’s a problem that roots to DirectSound.
So i guess this might answer your question then.
Might it be possible to enable buffering through the config so I can turn on when I’m not recording?
Possible i guess, but it most likely shall mean you have to restart Renoise if you want to change this aspect (regardless if you want to turn it on or off). Audiobuffering is determined upon driver initialisation.
I noticed 5-10% LOWER cpu usage on 2 of my songs. Both of them uses very heavy weight vst’s.
Im using M-Audio ASIO drivers here.
Yeah, with the ASIO drivers you have indeed lower CPU usage due to the SSE improvements that have been implemented. So you definately have a good reason to invest in a good ASIO card now.
hmmm… I hate being a poor student
by the way, please consider one vote more for “Nope… they’re actually lower”, and one less for “Yes, but not that much”, because I’m stupid and I’ve voted for the wrong option
neither nor over here
I have Pentium M 1.6 GHz here, 512 MB RAM. No such huge problems here… OK, no Edirol Orchestra but still with a bunch of bigger VSTi’s, the CPU usage seems very similar to what it was. However, the lack of buffering is noticeable so I also hope that this will be configurable in the end (even at the expense of disabling internal recording).
Not all of us have ASIO cards… yet
I think I’ll fill up a bug report on having an option for this. I don’t think it will made it to 1.8.0. Maybe for 1.8.1…
Just tried asio4all to see if that fixed it… but asio4all seems to think someone’s still trying to use the soundcard in some other way when I load up Renoise, so it disables the asio emulation. Odd behaviour… so I guess that doesn’t fix my problem
got exactly the same problem with ASIO4ALL on my 2ndary PC (P3-866Mhz + super cheap “Soundblaster PCI 128”).
not sure if it’s ASIO4ALL’s or renoise’s fault here.
I’m apt to blame it on the soundcard myself… I’ve got a soundmax chipset on my laptop… which probably can’t handle asio4all trying to hijack it’s way in as a low level device driver without shutting down all other sound processes
I just ran a quick test with two VSTi’s playing one three note chord on each. The CPU usage was pretty much identical. Not sure if this is subject to change where more and/or heavier VSTs are involved.
I have two computers: Evo n800w laptop (Intel P4m 2,2 GHz) and desktop with AMD Athlon 2100+, both using DirectSound.
CPU levels on desktop are quite same as with version 1.5, but I have noticed high CPU usage when working with Renoise 1.8b4 and laptop. Songs which use something like 40-50% of CPU on desktop use mainly same amount of CPU on laptop, but there are moments when CPU-usage grows dramatically and reaches 100%.
I hope you have not set your laptop CPU to stepping mode (you can turn it off in powermanagement and hopefully BIOS as well), because these specific power-saving mechanisms do not work well with any CPU intensive software.