Extreme CPU useage

[CoolColJ]

I'm trying out the v2.7 Mutools with Pianoteq v3.5 demo along with a D16 Drumazon demo plugin. After playing for a bit. I hear audio distortion and glitching and sometimes the overload meter comes up.

I thought this was odd, so I tried it in EnergyXT, and it showed half the CPU useage and no audio issues.

Funny thing is the CPU meter in Mutools reads higher than the windows CPU load meter.... I was getting up to 60-70+% CPU load in Mutools. While with EnergyXT, the same plugins, only peaked at 40-50%

Using an an MAudio Asio driver with 128 samples buffer size

[TheGuysanIdiot]

Hi

MULAB 2.X has always been a bit CPU hungry certainly when compared to XT2.

Jo is working on MULAB 3.X as we speak and hopefully that new version will be kinder to CPUs.

OZ

[bpblog]

not sure about eXT, but mulab 2.x uses only one core of your cpu. in example, if you have a dualcore cpu, mulab will use only half of it's power.

hopefully, M3 will let us push our cpus to the limit. ;]

[robenestobenz]

Hi

MULAB 2.X has always been a bit CPU hungry certainly when compared to XT2.

Jo is working on MULAB 3.X as we speak and hopefully that new version will be kinder to CPUs.

OZ

Ya. For audio Mulab takes about 3% (9% total) more CPU than XT2 on my PC for 10 tracks of audio, and about 5% (11% total) more for 20 tracks of audio, whether it be 10 tracks or 20.

For VST tracks, a quick test puts Mulab at 2% greater consumption, with 3 vsts or 10 vsts -- I'm assuming the amount holds with higher VST numbers, but I haven't tested this.

Scrolling around and changing zoom increases the CPU usage by a significantly smaller amount in Mulab on my PC.

//Edit: as it may be relevant here, Intel Q6600, 4gigs, XP64, MOTU Ultralite

[bpblog]

checked the eXT future list and it does indeed support multicore cpu's. hence the decreased cpu load.

[robenestobenz]

checked the eXT future list and it does indeed support multicore cpu's. hence the decreased cpu load.

Nah, it is planned as a future feature, but XT is not optimised for multiple cores yet. If it was, I'd hope to see more than 2-5% less usage!

I hope Mulab does this at some point... I know it's an enormous feature in terms of development time, but it's not looking like we're going to go back to single cores CPUs any time soon.

[MuTools]

MULAB 2.X has always been a bit CPU hungry certainly when compared to XT2.

I'm surprised to read this, especially regarding the use of VSTs.

Will do another test here too with Pianoteq.

[TheGuysanIdiot]

Jo

I am surprised you are surprised. You once told me that MULAB was a bit of a CPU hog.

And yes compared to XT2 MULAB is "a bit" (meaning small but noticable) more CPU hungry.

I use MULAB everyday as you know, I also like using XT2 I certainly can push XT2 harder than MULAB.

I just did a very quick test now with multiple copies of sylenth1 the more I add to MULAB the greater the CPU gap between the DAWs gets in the windows CPU monitor.

I love MULAB to bits as you know.

OZ

[Bonteburg]

I sometimes get significant spikes using just about any VSTi or MULAB synths.

Changing presets, playing notes for the first time and/ or using filters for the first time seem to be the culprits. Changing presets could also fall in the "first time" category now I think of it.

As for higher cpu usage than other hosts, I haven't another one to compare it to except Renoise and that's more a tracker.

Marco

[TheGuysanIdiot]

Hi me again,

Today I have done similar CPU testing with Reaper and my own trials seem to indicate that Reaper is even more CPU friendly than XT2.

To me the fact that MULAB may be less CPU friendly than the two above is no real concern to me.

MULAB is like no other DAW and all it means to me is that I have to write my songs in a more conservative way.

I also think my music has benefited from this as I limit my track numbers and reduce the amount of VSTi etc I use. It also makes me search out more efficient VSTi.

I am sure my music now sounds better using the "do more with less" approach.

I love MULAB's workflow and it is still my DAW of choice, despite any CPU issues it may or may not have.

I am sure M3 will be fantastic.

OZ

[MuTools]

checked the eXT future list and it does indeed support multicore cpu's. hence the decreased cpu load.

Nah, it is planned as a future feature, but XT is not optimised for multiple cores yet.
If it was, I'd hope to see more than 2-5% less usage!

I hope Mulab does this at some point... I know it's an enormous feature in terms of development time,
but it's not looking like we're going to go back to single cores CPUs any time soon.

I agree. Multithreading is the future (euh, the present). And MU.LAB should/will take advantage of it.

That's also one of the things i seriously took into account when working on M3. There were soms multithreading issues which were in the way of doing multithreaded audio processing anyway. M 3.0 itself will not yet do multicore, but under the hood things are already closer than M 2.x.

The M3 code base has been changed quite intensively between M2 and M3,
investments which should deliver more musical benefits in the following versions of M. But it was too much to deliver everything in 1 go. M3 already is a nice step forward, i'm confident about that. M3 is especially about improved usability comfort, as you will see soon.

On the fly latest update about M3: 10 days ago i discovered an essential problem in the new object system of M3. It took quite some time to properly sort out this problem (all seems fine now ), also because i don't like half work. The good news is that the code base even got stronger thanks to this extra R&D phase. Still to do: Some final tunings + inhouse testing-testing-testing! Looking very much forward to deliver M3 group test 1 asap. Sorry for the unexpected extra delay!

[MuTools]

I am surprised you are surprised. You once told me that MULAB was a bit of a CPU hog.

I must have been talking about the MuSynth/Mux, not VSTs.

The MuSynth indeed eats quite some cpu because no compromises are made on sound quality. The MuSynth will be furtherly optimized for efficiency wherever possible but sound quality must be perfect!

Elaborating more on this:

If we want to get more MuSynth out of a machine, the solution should not be to compromise on sound quality, but the solution will come from

1) furtherly optimized routines (using SSE etc)
2) a smart freezing system (already dreaming/thinking about this things step by step, effective R&D planned for a future version)
3) multicore support

Back on topic: I'll research the reported higher cpu usage for vsts asap.

[MuTools]

I sometimes get significant spikes using just about any VSTi or MULAB synths.

Changing presets, playing notes for the first time and/ or using filters for the first time seem to be the culprits. Changing presets could also fall in the "first time" category now I think of it.

As for higher cpu usage than other hosts, I haven't another one to compare it to except Renoise and that's more a tracker.

Bonte, did you already had the chance to expand your compu's RAM?

I do think it will help regarding these issues!

[MuTools]

Thinking loud about multicore support: Last night i had this idea:

Maybe each MU.LAB Session could have more than 1 MPA. Each MPA runs in a separate audio thread i.e. a separate core, when available.

Compare each MPA to a studio room full of equipment which is hooked up to eachother in some way. Then each studio is ran on its own core.

It's a very simple solution, and technically it also has the advantage that core X won't have to 'wait' for core Y until core Y finished processing a plug which delivers data core X needs, because these studio rooms are fully independent.

The disadvantage is that it is the user who will have to 'spread' the plugs over the different MPAs (studio rooms), which may be a bit less comfortable than a fully 'automated' multicore audio processing algorithm (that may be less efficient than doing it manually because of having to resolve plug dependencies; still need to do a lot more research on it)

But i think this disadvantage may be minimized by the advantages:

* having multicore processing available
* multicore processing itself will be done very efficiently (independent rooms)
* the user has fine control over multicore processing (user knows which plugs are most heaviest)

If one of you has experience/knowledge in how to properly do multi-threaded audio processing, feel free to share, i'll be listening with interest!

NB: I may react lazily on this topic as current main focus is on finishing M3.

[bpblog]

Thinking loud about multicore support: Last night i had this idea:

Maybe each MU.LAB Session could have more than 1 MPA. Each MPA runs in a separate audio thread i.e. a separate core, when available.

Compare each MPA to a studio room full of equipment which is hooked up to eachother in some way. Then each studio is ran on its own core.

whaaaaat? this is BRILLIANT! i would love to se this idea come to life. total cpu control ftw!