Bitwig

Erwin78 · Post by **Erwin78** » Thu Oct 30, 2014 12:08 am

My CPU is an AMD FX8350
It seems Bitwig does not make full use of all it' s cores.
I have read many articles already (also on KVR) but can't find a solution.
I already tried the windows performance/core settings and such.

The process Bitwigpluginprocessp64 does not want to use more than 4 cores.
Even not when having all the plugins in a separate process and setting affinity to different cores.
Also when setting affinity to the cores not being used before only one of those cores will be used.

Anyone else with such problems?

ThomasHelzle · Post by **ThomasHelzle** » Thu Oct 30, 2014 10:33 am

Threading in Bitwig Studio is per-Track, so it depends on your project how well the load can be spread over CPUs. But performance for realtime audio depends on many other factors too, it's not like 3D-rendering where you can pretty much get all cores to max out. With audio, performance also depends on your audio drivers, if you use a lot of samples and audio clips, harddisk/bus-performance may come into play, background processes can make the CPU switch too often to other stuff etc. therefore the internal DSP meter is not a 1:1 CPU meter but shows how much headroom is left for the applications to do it's work with the resources at hand.

Some plugins like Diva or Kontakt have additional internal multithreading so they can spread individual voices over several cores, which can help in cases where you don't have many tracks, but it can get in the way otherwise.

You also have to keep in mind that Bitwig consists of several processes: A Java GUI, a C++ audio engine and then the plugin hosts that depending on your settings in preferences are either one per plugin or one per architecture (32/64 Bit) or even less with the new setting in 1.1 Beta where plugins can run directly in the audio engine (but you lose the crash protection).

So in conclusion: for realtime audio, you should actually not see cores maxed out, similar to how you don't record audio too hard at the edge of clipping. It needs some space to breathe

Cheers,

Tom

tor.helge.skei · Post by **tor.helge.skei** » Thu Oct 30, 2014 11:50 am

ThomasHelzle wrote:the new setting in 1.1 Beta where plugins can run directly in the audio engine

didn't know that!! awesome!!
- tor-helge

ThomasHelzle · Post by **ThomasHelzle** » Thu Oct 30, 2014 11:55 am

Yeah, just be aware that you lose the sandboxing/crash-protection (although the GUI will not crash, the audio engine will if something goes wrong with a plugin) and that this only works for the architecture you are running on, so for instance on 64 Bit Windows, only 64 Bit plugins can run in the engine, 32 Bit ones will continue to be bridged.
It's the third option "Only as bit-bridge" in preferences.

Cheers,

Tom

goatgirl · Post by **goatgirl** » Thu Oct 30, 2014 12:18 pm

This new plugin mode sounds very interesting and another little gem hidden within the next version. To avoid any assumptions, may I ask what is the intended purpose of the new 'bit-bridge' mode?

ThomasHelzle · Post by **ThomasHelzle** » Thu Oct 30, 2014 12:27 pm

Well, in theory it could be a bit faster if the plugin runs in the context of the audio engine directly instead of in an in-between plugin host.
I personally always run all plugins independently though, since I have no performance problems and love the crash protection of the first option.

Cheers,

Tom

jeffh · Post by **jeffh** » Thu Oct 30, 2014 12:33 pm

Erwin78 wrote:My CPU is an AMD FX8350

I have the same CPU. For maximum performance, I'd recommend going into the BIOS and turning on the "one core per module" feature that makes the OS recognize it a quad-core, and you probably also will want to disable the C1E state (and any similar states that turn off CPU cores completely). Most aftermarket motherboards expose these features, but OEM motherboards may not...

Erwin78 wrote:The process Bitwigpluginprocessp64 does not want to use more than 4 cores.

That's by design I would assume, and for good reason. I've done a lot of audio benchmarking, and I've consistently come to the same conclusion that utilizing more than 4 cores usually provides less CPU power and higher latency than using 4 or less, unless the developer resorts to some ugly brute-force optimization like anticipative pre-buffering of the plugins. This is mostly due to cache latency and resource contention to keep the threads synchronized, it gets worse as you add more threads.

TeotiGraphix · Post by **TeotiGraphix** » Thu Oct 30, 2014 12:36 pm

goatgirl wrote:This new plugin mode sounds very interesting and another little gem hidden within the next version. To avoid any assumptions, may I ask what is the intended purpose of the new 'bit-bridge' mode?

Anytime you bridge/proxy objects in code it multiples the stack calls and adds to RAM(the bridge instances).

Either way, getting things closer to the "metal" will perform better.

Analogy, talking to someone on the phone verses talking to them in person, you eliminate the wires of communication and latency factors as well. (could be minute, but could be huge)

Mike

goatgirl · Post by **goatgirl** » Thu Oct 30, 2014 12:44 pm

Cool, so it is just to save system resources. As it's a departure from one of Bitwig's features I had to ask.

Though I guess it's only advisable with trusted plugins or ones that are CPU hungry. Given the new breed of synths and effects I can see any resource saving as a good thing.

Thank you

TeotiGraphix · Post by **TeotiGraphix** » Thu Oct 30, 2014 12:49 pm

goatgirl wrote:Cool, so it is just to save system resources. As it's a departure from one of Bitwig's features I had to ask.

Though I guess it's only advisable with trusted plugins or ones that are CPU hungry. Given the new breed of synths and effects I can see any resource saving as a good thing.

Thank you

There is always a trade off in software development with safety verses performance.

True to real life as well.

It's always a balancing act and its no coincidence that Bitwig offers a new performance feature AFTER they implemented the safety feature.

Mike

Eta Carinae · Post by **Eta Carinae** » Thu Oct 30, 2014 2:30 pm

I won't be turning it off - the VST sandboxing is one of Bitwig's most useful features IMO. I really like being able to get stuck into a project, without having to worry about losing my work due to a crash.

Although Bitwig still crashes, but I'm hoping that'll be sorted out in future versions.

Eta Carinae · Post by **Eta Carinae** » Thu Oct 30, 2014 2:32 pm

As far as multi-threading goes, I find that Intel's Hyperthreading does give you added performance. But it's nothing like having 4 extra cores, at best it's maybe 1 or 2 extra cores. But there's definitely a performance boost.

Erwin78 · Post by **Erwin78** » Thu Oct 30, 2014 9:08 pm

Thanks for all the responses.
Unfortunately my MB doesn't support disabling a core per unit. But it seems Bitwig already chooses the cores wisely.
I was hoping to get more performance with setting affinity seperately for the gui and audio but that messes things up.

@ThomasHelzle: If I route audio from one track to another. Does Bitwig count that as one track core/processing wise?

ThomasHelzle · Post by **ThomasHelzle** » Thu Oct 30, 2014 9:15 pm

The second track has to wait for the first track to finish in that case anyway, so I guess the principle still holds, but in 1.1 with the receivers the whole thing got rather complicated so I wouldn't want to give definite answers for all cases.

Basically modern OS' and apps do the whole multithreading thing on their own quite well and chances are you create more hard-to-track problems than you solve with tinkering manually.

I don't really think it's worth it anymore, especially Windows 8.1 is very good with balancing it's power.

Cheers,

Tom

Erwin78 · Post by **Erwin78** » Thu Oct 30, 2014 9:36 pm

Thanks Tom.
Back to autopilot.

Bitwig

KVR Audio

CPU/Threading