For a while now, I've used a majority of Image-Line products which are very CPU-friendly and not very resource intensive (compared to using 3rd party stuff). But now that I'm expanding to use more instances of 3rd party plugins, they are eating up my CPU... or so I thought.

FL Studio's CPU meter will report that I am using 100%, and I will start to hear pops and clicks. Task Manager on the other hand will report only an 8% to 16% usage of my CPU. Now, I've seen Image-Line's video of saying that eventually, if continuously played, the Task Manager will report the accurate usage that FL Studio's CPU meter is reporting... but it is not happening.

I am not interested in merely changing the buffer size (it doesn't help much anyway). I have two CPU's, both quad-core. Eight cores in total, and all of them are in use (so it's not a parked/unparked issue). If there is a way for FL Studio to use up all my CPU (8%-16% is downright pathetic, let's be honest), I would like to know. If Image-Line's insistence that FL's CPU meter is more important, then I assume it's my Audio Interface.

...WELL THEN. I'm using Avid's MBox Pro 3 on Windows 10. It seems like they discontinued the drivers for Windows, which seems to be a problem because it continuously disrupts audio, shuts down, and gives me BSOD. Those bugs aside, it doesn't seem like the Soundcard is capable or powerful enough to maintain the new 3rd party plugins I'm having so much fun with.

So if it is a CPU issue, how would I let FL Studio use my CPU space to its full potential?
And if it's the MBox, which audio interfaces would you recommend? I would be looking more for the power of the soundcard of course, disregarding how many channels it has (I only really need two).

OR MAYBE IT'S BOTH. I don't know. HELP ME!

Ah, okay. Yeah, Multi-Threaded generator/mixer processing has always been a hit or miss for me, and probably has something to do with the third thing you told me there. For the second, yeah it does, and it's not an ASIO issue, it's just my faulty audio interface.

But that's what is still confusing then... that the CPU isn't being used to its full potential.

Interestingly enough, some 3rd party plugins don't have the option to be multi-threaded, but Task Manager reports all cores are being used and active, just that every core is at 8% to 16%.

...but Task Manager reports all cores are being used and active, just that every core is at 8% to 16%.

Huh. If all of FL Studios multi-threading options are enabled, I have no clue what could be wrong. Maybe try switching to ASIO4ALL and see if that works better. It's possible that the MBox driver is creating thread stall in some way, and the ASIO4ALL, FL ASIO, or DSound driver won't have that problem.

Quote from: Aerithos on January 13, 2016, 01:33:41 pm

Huh. If all of FL Studios multi-threading options are enabled, I have no clue what could be wrong. Maybe try switching to ASIO4ALL and see if that works better. It's possible that the MBox driver is creating thread stall in some way, and the ASIO4ALL, FL ASIO, or DSound driver won't have that problem.

Interestingly enough, both ASIO4ALL and FL Studio ASIO perform slightly worse than the MBox's ASIO driver. I'm not sure if this next bit of information is important, but when the CPU load goes up to 100 or above, the options settings where it says... 'Underruns: #' stays at 0.

So, you wouldn't say ditching the MBox for a better Audio Interface/Soundcard would help since they don't do any processing themselves?

It could be the Audio Interface that is stalling and not the driver. If the system has an internal soundcard, try testing that with ASIO4ALL. Or borrow another Audio Interface and test that. If they exhibit the same issue, then hit up the Image Line Forums and ask in the support area there (and make sure to link this thread).

But a little detail on what I think may be wrong. When FL Studio finishes processing all the plugins and calculating a sample, it sends that sample to the output sound buffer, in this case, the MBox hardware buffer. If that buffer is currently unavailable, then FL Studio needs to wait until the buffer becomes available again before moving on to calculating the next sample.
Things that can make the buffer unavailable:

• Broken Sound Card/Audio Interface - Test by trying a different Sound Card/Audio Interface
• USB/Firewire Communication Issues - Test by trying a different port or cable
• Sound Card/Audio Interface Driver Issues - Already tested by trying ASIO4ALL

But that's the extent of my knowledge, so Image Line would be the next valuable information resource...

I don't have a solution to your issue (sorry), but my two cents is be careful when using ASIO4ALL. I had similar issues where my track would not buffer and I would have terrible crackles when playing my track, so I did all the latency and other bs solution stuff.

Someone suggested switching to ASIO, and sure enough it fixed the problem... until I had a new problem. Everything sounded different.  Way. Fucking. Different.

My first questions were, what the hell will my song sound like when played somewhere else? How the hell can I EQ and mix if I don't know which sound is correct?

it could be a virus hahah jk

I found the source of the problem.

I have two CPU sockets, and each CPU has 6 cores, 12 cores in total. I believe the issue was that the CPU was feeling stressed due to the amount of designation tasks to all those cores, which it wasn't doing a very good job of anyway.

I limited the number of active cores to 2, and since there are 2 CPU's, 4 cores are now active. It increased performance by almost 80%! FL Studio itself no longer reports 100%, but 60% maximum of one particular session file... and so does the CPU.

Strange, but I think the category of my CPU is important, as they are made for servers, meaning a workstation computer.

Huh, definitely forward that result to Image Line. It sounds like FL Studio isn't effectively handling multiple processors. I'm guessing that the issue comes from expecting data to be available in the L2/L3 cache or registers in a thread on one processor that is actually from a thread on the other processor. Possibly some latency issues too, especially if two threads split between the processors have alot of interaction.