CPU performance in Buzz (general tips and tricks topic)

[Dean]

this is now a general topic to discuss cpu performance in buzz, giving tips for optimization
so that we all can enjoy real-time audio, instead of a stuttering mess, without compromising the number of machines we use.

original title: CPU performance in Buzz 1349 much better than latest build!
edit: original topic start can be read below:

I've been using an older build until today but I decided to give the new one a shot...
Sadly, I was disappointed. and I'm back to using an older build. Here is why:

First of all, I hope this is not taken the wrong way. I know how much hard work goes into this lovely software, and I hope it is being under development, even if it means demanding more technology from the user.
I have some concerns about the updates since 1349 (I remember reading this is a "classic build", and this is what I went back to using), which might not be solely about the latest release but about every release leading up to it:

1. My CPU performs (significantly) worse in latest version compared to "classic build"! And surprisingly, if I active the multi thread option, the cpu consumption goes up(!), instead of down which makes no sense. I am wondering why does buzz suddenly consume so much more cpu and why does multi-threading increase cpu use? It's like bizarro world for me.
I'm on an i7 cpu, using windows 64-bit (ram is far more than necessary), if it gives you any needed info. Let me give you an example of how much worse the latest version performs:
* A file which was peaking my cpu in a non-multi-thread mode would take around 6:20 (6 minutes 20 seconds) to "play through" on the old build (not sure exactly which one, but around "classic build").
* Same file in the latest build takes a whopping 7:20 to play through! One minute more!
* Same file in the latest build in multi thread enabled mode takes another 55 seconds to play through(!!!), so all in all it takes 8:15 to play through.
Because cpu is peaking the song takes longer to play through than the length of the song, I get that, that's the way it is.
But what is up with taking so much more cpu power compared to an older build? (I know the cpu power is heavy cause of what's in the file (around 100 generators, and a lot more effects) but why did it work out so much better in the older build?)
After trying out the latest build I made sure by checking with the old build again, and it's still much better cpu-wise, it was not a coincidence.

2. I also opened some other less cpu-heavy files (around 15% cpu on my i7, I don't know maybe 15-20 machines?) and although the difference between "classic build" and new build is very small (just a few %), it's still true that that multithreading is actually increasing cpu usage on my i7 cpu on the latest build (whereas on the "classic build" multi threading helps decrease overall cpu load)... it really doesn't make any sense, why single thread cpu use would be more effecient?

3. This is not a complaint but an observation, which might be able to partially answer the mystery of why cpu usage is so different in these versions
(it won't answer why multi thread increase overall cpu usage though).
In "classic build" if I use audio driver "silent" it will take 10 minutes to extract the same song which would take around 6:30 using a driver like WWA(!).
ASIO driver also takes a lot of time, around 9:30.
Now I don't mind takin' sum extra minutes to extract a song in "best quality" with best driver, but while working (preferably in real time ) I just want
a driver which gives good performance (sure - being able to hear all details is important, but you can forget about that anyway when your cpu starts
peaking, that's a much bigger problem.). So the ability to switch between drivers is essential to cpu-demanding work, but given the fact that the latest
build performs very poorly in comparison to the "classic build", it makes no sense to chose it (if what you want to do in buzz is cpu-demanding).
What might have been done to the newer builds which makes cpu usage more heavy?

Questions about new build about features I didn't understand:

4. What's up with the new audio recorder? All I get is an empty file (it has a length, but no data inside). Did I miss something?

5. "Multi groove" support sounds very interesting...! but how do I use it?

6. (minor complaint) "Bursts" doesn't sound the same as before. I learned to love the bursts of the past, now they sound awkward. Granted, I don't want bursts when I open files, but still...

I hope this rant can bring up a discussion about this serious issue, but I hope it doesn't put anyone off.
I just want to be clear with what is an issue for me with the latest buzz,
and why I will stick to "classic build" until the cpu issues are resolved. Considering how technology moves forward,
(and it's more common to make consumer buy more hardware than to redo code which makes cpu usage more effecient)
I think maybe they will never be resolved...
Maybe I'm not the only one with this experience? There are some new features which look cool, but they are not something I need,
especially not at the cost of such a higher cpu performance. Multi groove sounds super cool, but I don't know what it is and how to use it...

[UNZ]

if you are able to max out an i7 there's something very very wrong with your setup / bmx etc

whats the cpu load on an empty bmx ?

maybe you have some denormal issues or machines causing problems, can you make a screenshot of your bmx and one of the cpu window displaying how much cpu each generator takes


it is entirely possible for multithreading to be more demanding than single threading, it all depends on how your particular bmx will be threadable. It can also cause overhead.

[mantratronic]

Any chance you can give some example bmx's? It's hard for me to understand how you are maxing out an i7 given I have and i3 and its only cpu heavy vsts which cause me problems.. I dont understand how you're getting empty files from the recorder, works fine here.. You're right that multithreading can cause more cpu usage on small buzz setups, thats one of the catch 22's of computing though, and isn't buzz's fault.

[Joachip]

I've been using an older build until today but I decided to give the new one a shot... Sadly, I was disappointed. and I'm back to using an older build. Here is why:

... snip ...

6. (minor complaint) "Bursts" doesn't sound the same as before. I learned to love the bursts of the past, now they sound awkward. Granted, I don't want bursts when I open files, but still...

I'm sure someone could write a machine to randomly insert old-school Buzz noise bursts if you're feeling nostalgic!?!

[ags]

6. (minor complaint) "Bursts" doesn't sound the same as before. I learned to love the bursts of the past, now they sound awkward. Granted, I don't want bursts when I open files, but still...

[strobotone]

never been able to max out core i7.
please attach a non-vst bmx for testing and post how it behaves differently with multithreading enabled/disabled (cpu monitor>cpu usage/overhead).

[Buzztler]

I also have still problems here, but I found something surprising:

I switched back to build 1453 and loaded my latest bmx with the default theme. I opened the task manager to see my real CPU load, not the "new internal CPU monitor". If I play this more or less simple bmx the CPU goes sometimes up to 100%.
Now I did something very useful: I simply opened a menu position but I didn't make any choice just left the menu open ... The cpu consumption was reduced immediately by 50% through the whole track, I only used buzzmachines, no vst/vsti ... it works for every bmx I load ... funny I'll stay on this build for a while 'cause I have no chance to reduce cpu in the new builts 'cause the menu has changed ...
Furthermore I found out that in the debugger-window there is some lines showing some msc80? (assembly?) or so is missing on my computer ...

[strobotone]

can you please copy and paste the debug line here (and optionally the bmx).
which os?

[fetus ink]

And please do not call build 1349 the "classic" build, as its hardly so, and gives people the wrong impression. As I can see it had you fooled. Down with the rumors!

I am also running the newest build on an i7 x64, and have never peaked using old songs, unless they were songs that always did have a problem, and the ones that did were always vst heavy. (By old I mean any song written before build 1349) - granted, I'm not home to actually compare cpu usage right now, either.

Ill take a look at the bmx as well when its been posted, but as far as I know, the only thing that broke for me from around that build was the ability to load ILok vsts without crashing buzz, and that may have already been fixed lately. Haven't tried.

[Buzztler]

Thank for your fast reply Strobotone ... I'm not at home at the moment, so I cannot post the lines or the bmw, but as I said it works with every bmx/bmw I use).
It could be a graphic-driver problem ... 'cause the driver is from 2009 and uses .NET 2.0.
I just wanted to mention it here 'cause I didn't recognize the high cpu consumption in earlier builds-I only watched the internal CPU-meter, not the win-task-manager, but I never had sound dropouts before.
I know I use a strange Buzz setup and some older hardware 1.8 Ghz Athlon, but how can it be that an open menu reduces the cpu consumption of Buzz 50% during playback with ASIO-enabled? (... you can find the bmw on buzztunes)

[strobotone]

alright. i can not answer the question but it is probably not graphics driver related.
but you could update to .net 4 on winxp (+sp3), latest buzz build and check if the problem is gone.
only the wpf part is depending on your graphics card (hardware accelleration).
even if the entire gui was wpf-based the cpu usage would still be 0% with an empty machineview.
if it does not support all the wpf features then your cpu will do.

and some might sometimes forget that buzz is one of the few music applications today that only uses cpu-power when required.

btw. what does your cpu usage say while buzz´s output is muted? (F12 key)

[Buzztler]

Thank you Strobotone ... in the lines of the debugger there was mentioned wpf (as far as I remember) so it seems u answered the question already I'll check it even if I don't like SP3 and after making a backup

[strobotone]

sure
you could try to install .net 4 without sp3 first. maybe it works.
those service packs are mostly a collection of previous KBs anyway.

[Dean]

First of all, let me say thanks to all who replied so far, I really hope we can solve the situation here as I would be happy to update, but I won't do it if it brings down the cpu quality...

Now, it should be mentioned I don't use any theme, I use nothing which can take cpu power except things which makes sound.
Cpuload on an empty bmx is 0,1%, roughly 0 that is.
Inserting one Qsamo (not editing at all) cost me an average of around 1-3%, on multi-thread CPU, less than 1% on single thread cpu.
I can not attach the file in mention, it is 17 mb after I've deleted all samples, and it's not something which I want to make public at this time. But yes, it has a ton of machines and patterns, and you can also notice this in that when you for example enter into pattern editor, it takes like half a second (this is instant when you start anew or is working on a smaller project, or hide new sequencer).
The cpu usage on this bmw/bmx, just after opening it, is around 25% on single thread, switching to multi threading is around 30%.
There is no visible usage on any machine in cpu usage list, except for one vst which has 1%, so I think it's because there are so many tiny usages by all the other machines, around 0-0,1% - which can turn into a lot if you got more than 500(!) machines in the song (which I do). (in sequencer more than 100 tracks)
I am quite astonished by this number myself, I haven't counted until now, but yes, that's the way it is.

The numbers of 25%/30% are from the 1349 (I will from now refrain from using "classic") build.

Installing the latest build (buzz should get credit as for how easy it is to swap builds!) I get the following numbers:

Single thread: 40-48%, Multi-thread: 60-65% --- note that these are the numbers I get from just keepin' the project open.
Overhead is around 40% on single thread and 50% on multi-thread. Nothing is playing!
Note that the cpu monitor shows most machines as 0%, and a few as 0,1%, only one is shown as higher than 0,1% (it has 1%).
So I do think the sheer amount of machines come into place. Think of 1000 snowflakes, they can make a snowball, which can break a window,
but window can not be broken from those flakes on by one...

As I mentioned, the old sequencer does not take any time to load up - it's instant.
The first time I enter the pattern editor - the graphics kinda freeze for 2 seconds before I can do anything. Then it rolls on as usual.
If the new sequence editor is hidden - it rolls on well, but if it is activiated, there's a lag, like half a second or something,
every time I enter a pattern or want to make a new pattern or anything.

even if I disconnect all machines from master (using newest version) - which means no sound can be produced, the cpu usage is around 16% single thread (and basicly
the same, maybe slightly higher multithread).

any thoughts?

oh and what about multi-groove? how to use it? (no topic on this forum, I can make a new one if we want to make this topic about cpu process)

edit:

On a side-note I have been making a lot of songs in newbuzz and this is the only song which cause problems with cpu peaking since starting using an i7 cpu.
But usually I don't make projects of this size. Some of it could be sampled and recalled of course, and that's how I'm editing as of now (I extract part of song
which functions as background when I'm working on other group of layers)

[UNZ]

it sounds as if its not audio-thread related, but something with the gfx-thread thats going wrong.
Or maybe ngen not working properly.

i'm quite puzzled as to why your bmx is 17MB without wavs, that seems very wrong, how many machines and patterns do you have exactly ?
It should be a few KB really.

Please make a screenshot so we know what sizes we're talking about. If you want the problem fixed you'll have to share some info, preferably the bmx but a screenshot would tell a few things too.

[Dean]

it sounds as if its not audio-thread related, but something with the gfx-thread thats going wrong.
Or maybe ngen not working properly.

i'm quite puzzled as to why your bmx is 17MB without wavs, that seems very wrong, how many machines and patterns do you have exactly ?
It should be a few KB really.

Please make a screenshot so we know what sizes we're talking about. If you want the problem fixed you'll have to share some info, preferably the bmx but a screenshot would tell a few things too.

maybe I'll try to sort it out later, but I don't see how it will help (I can not take a screenshot of anything that will show anything I haven't described already). there's roughly 90 generators, over 400 effects in use (not simultaneously of course, though sometimes a majority is used at once), I'm not sure how many patterns, would be difficult to count, more than 100 columns in the sequencer, but the old sequencer flows fine, I can't think of an average amount of patterns though.. (can I write something in debug or something to know how many patterns?)
Actually I've had some big project in the past (oldbuzz) where I used thousands of patterns, where file-size was also several megabytes in size, stripped of waves, it's easy to add up once you get started with certain bigger projects.

I think your guess is great, it's probably graphic-related, because the newer builds has had updates which the older builds obviously doesn't...
Clickin on the "parameters" switch (next to templates) is a big-no-no, unless I want to wait almost 40 seconds doing nothing.

[strobotone]

ok. so you use like 500 machines. why?
is there no better way?
i am sure you have your reasons and buzz can handle a virtually unlimited amount of machines.
(not meant to be personal

however. yes, you are correct. adding machines that use displayed 0,0% cpu is still adding up
in case of cheapo amp i added 500 to the machineview and they add up to 45% cpu usage.
but if i select any of them and press enter i immediately end up in the pattern editor. no lag at all. (core i7 notebook)
so the graphics adapter (cpu-integrated) is not a problem in my case atleast.
(but the machineview and sidebar will become a bit slower ofcourse)

sorry that this does not help but i also tested with more than 750 Matilde Tracker 2 in machineview and old sequencer.
still able to work relatively fluently.

the bmx filesize is about 1.2 Mb (no patterndata). if required i can attach it.

[Dean]

ok. so you use like 500 machines. why?
is there no better way?
i am sure you have your reasons and buzz can handle a virtually unlimited amount of machines.
(not meant to be personal

hehe, not normally, but in this project, it's not a normal song . The "focus" of the song
is more of a jungle than carefully put in center.
I've taken the chance to enjoy exploring the world of sound in this one, and to focus more on detail than the music
as a whole...
Technically I'm not trying to push limits, I would love to had known about the limits before starting on this one,
cause then I could have made better choices... as I mentioned, there were never any limits to run into before,
so I didn't think there would be working on this.
I actually do think "less is more" (and I tend to like minimal music myself) but for this project I wanted to do something
crazy and work with a lot of details...
Maybe my background is related, I used to do noise way back, adding a ton of distortion effects on one sound only,
learning how it shapes the audio, I guess I use that experience even when working with "clean" sound.

however. yes, you are correct. adding machines that use 0,0% cpu is still adding up
in case of cheapo amp i added 500 to the machineview and they add up to 45% cpu usage.
but if i select any of them and press enter i immediately end up in the pattern editor. no lag at all. (core i7 notebook)
so the graphics adapter (cpu-integrated) is not a problem (in my case atleast).
(but the machineview will become slower ofcourse)

Thank you for trying out maybe we can find a solution to this, I'm sure what you just did would run smoother
in 1349. I tried some versions in between from 1349 up until most recent, and it seemed that a bit gradually did
the cpu usage increase... for example 1364 could take up until "30 seconds more" than the 1349... there are not
that many updates in between, and may have nothing to do with cpu but the effect of the updates (on cpu)
are much more noticeable when using 500 instead of 5 machines.
And of course, I do know, for most normal traditional genres and music, this is not a problem,
But if we can solve it, I'd be very happy (or maybe I'll just update in the future when I'm not working on this anymore)

[Dean]

sorry that this does not help but i also tested with more than 750 Matilde Tracker 2 in machineview and old sequencer.
still able to work relatively fluently.

I think it helps, I appreciate it a lot! wow, that's a lot! great pic by the way... Are they connected to the master?
if they are not connected,they will take up much less cpu, and also of course, the main problem is not idling here, but the cpu usage when
you play the song (which makes it impossible to work in realtime). Of course 1349 build is also "impossible" in real-time but when working
under such a heavy load of cpu, the difference is big enough to make a difference!
(I can use more stuff real-time instead of sample, in old build, it's very noticeable)

[UNZ]

i added 500 machines to machine view and yes it gets slow, especially when the parameters column is open in machine view, all of window's graphics crawl to a halt etc. But ok, i REALLY doubt you need 500 machines in the first place..