VEPro 5 CPU issues in Cubase

[Zelorkq]

Hi!

Not sure where to post this.

I’ve had this problem since building my big template. I’m using Cubase 7.5.30 (same issue with 6.5, 7.0…7.5.2) and have VEPro 5 load all of my instruments and Cubase only the MIDI tracks. Something I’ve noticed is if my audio device is connected and I connect my VEPro 5 instance, the CPU usage jumps to around 35-40% and stays there, jumping around ±5%. Playing back my piece will then easily give me 100% CPU usage, seeing that I only have 60% left. Thus I have to push my audio buffer way up (1024 or more) to compensate, which increases the latency extremely…

I’m using VSL MIR in VEPro 5, which is a CPU killer already so I need every bit of CPU power I can get out of my Intel Xeon E3-1230 v2, 32GB RAM (Win 7 x64). I’ve been in contact with VSL and they believe it has to do with the whole re-routing of audio and that Cubase doesn’t like that. I don’t know what causes this problem, let alone how to fix it. I use a Creative X-Fi Platinum soundcard with the 2.11 Asio4All drivers. However, I just got a new Steinberg UR22 and installed the latest drivers and tried it out. Result? Exactly the same, so its not an audio device or driver issue but somehow a Cubase <-> VEPro issue.

Side-note: All VEPro instances are decoupled. I’m using Audio Input Plugins to re-route my instruments from a secondary PC which also uses VEPro (re-routed from Slave PC to Cubase to the main VEPro instance for MIRing). I tried deleting every one of these plugins and my CPU usage went down from 35-40% to 25-30%. An improvement, but still far from optimal. My main VEPro uses 32-40 MIDI and audio in/outputs. However, I also tried pushing them down to 8 only and the CPU usage didn’t really change, maybe a few % less…

Does anyone know what the cause could be? Or if there is a possible solution or workaround, other than getting a big 6 or 8 Core CPU?

Thanks in advance.

Regards

[roel]

Each instance in VEP has its own buffer settting (in the server window) so there you can try to raise the ones that only have to play back. And you can assign specific cores to an instance in VEP. These tools should give you a way to optimize the performance.

Since there are a lot of unknows in your post i guess you are referring to the CPU usage (and not the asio usage). That is good.
If you load the vsti’s in VEP it is normal that your CPU usage goes up (indeed dependent on bufffer size and type of vsti) 40% for 40 vsti’s is not that much, but since they are loaded and active they should not go trough the roof. So you need to pin down what is causing that.

-There is very little info on what type of plugins you are using, but even when using a powerfull core like the Xeon E3, you should easily be able to load up to 40 instruments. The way they are spread out over the instances, and the way those instances are allowed to resources is very important though.

To get insight in your setup you could assign a single core to each instance, so you end up in your case with 6 or 7 instances for the main VEP. (i guess with one 64 bit server f.e.) (leave one or two cores for cubase and the OS)

Once you start filling up the instances you can monitor how the assigned cores handle your vsti’s.
Also you can spread your vsti’s over the cores in a balanced way.

But there is more.
You also use a slave machine.
That one takes resources too.

(edited)
The cores are assigned in the external machine, but it takes resources from the main machine as well. So this should take resources from the one or two cores that are left over for cubase and the OS. So if the problem is there, then you know you have to add resources to that specific part of the setup.

So building up things by carefully assigning instances to specific cores (and playing with the buffer size for that insance in function of what it has to do) should give you the tools to optimize your setup and get the most out of the system.

It is just my opinion. Maybe some of the other people here that are VEP-users have a different approach.
I’ll be interested to here their input on the subject.

kind regards,
R.

[Jalcide]

You might try using the Windows’ Affinity feature to prevent Cubase from using one (or two) cores.

Do the same with VEP on the opposite cores.

http://www.techrepublic.com/blog/windows-and-office/change-the-processor-affinity-setting-in-windows-7-to-gain-a-performance-edge/

I haven’t test this with Cubase and VEP, but have with Cubase and Reaper and it works well in situations where ASIO performance leaves much of the CPU underutilized (almost all cases), and where another app could fit inside what’s left over, CPU-wise. The Affinity allocation prevents each app from stepping on the another’s toes and prevents Windows from re-assigning threads / cores at inopportune times (which for real-time audio, is always).

[Indigo]

I use VEP 5 with one master and two slaves. The master is i7 4770k/32g, the slaves i3770k/16g. Occasionally I even add my laptop to the network (also i7-based/16g.) I’m not experiencing the slowdowns you mentioned. I think it’s either a configuration issue (Cubase, VEP, Ethernet or Windows, for the record: I use 8.1) or an audio interface issue. I use RME UFX, but I’ve heard from a couple of people who use other devices (M-Audio in both cases) that they did encounter some problems with VEP.

[Zelorkq]

@roel

Each instance in VEP has its own buffer settting (in the server window) so there you can try to raise the ones that only have to play back. And you can assign specific cores to an instance in VEP. These tools should give you a way to optimize the performance.

Since there are a lot of unknows in your post i guess you are referring to the CPU usage (and not the asio usage). That is good.
If you load the vsti’s in VEP it is normal that your CPU usage goes up (indeed dependent on bufffer size and type of vsti) 40% for 40 vsti’s is not that much, but since they are loaded and active they should not go trough the roof. So you need to pin down what is causing that.

-There is very little info on what type of plugins you are using, but even when using a powerfull core like the Xeon E3, you should easily be able to load up to 40 instruments. The way they are spread out over the instances, and the way those instances are allowed to resources is very important though.

To get insight in your setup you could assign a single core to each instance, so you end up in your case with 6 or 7 instances for the main VEP. (i guess with one 64 bit server f.e.) (leave one or two cores for cubase and the OS)

Once you start filling up the instances you can monitor how the assigned cores handle your vsti’s.
Also you can spread your vsti’s over the cores in a balanced way.

But there is more.
You also use a slave machine.
That one takes resources too.

(edited)
The cores are assigned in the external machine, but it takes resources from the main machine as well. So this should take resources from the one or two cores that are left over for cubase and the OS. So if the problem is there, then you know you have to add resources to that specific part of the setup.

So building up things by carefully assigning instances to specific cores (and playing with the buffer size for that insance in function of what it has to do) should give you the tools to optimize your setup and get the most out of the system.

It is just my opinion. Maybe some of the other people here that are VEP-users have a different approach.
I’ll be interested to here their input on the subject.

kind regards,
R.

Thanks a lot for your reply roel, I greatly appreciate it!

Exactly I meant the actual CPU usage (Task Manager). My ASIO usage is doing just fine (on both devices).

My main plugins/instruments for this master PC Instance are Vienna Instruments Pro, PLAY and maybe one Kontakt instance (My slave PC handles all other Kontakt instances and others). Additionally to that comes VSL MIR and VSL Suite. Other effect plugins only seldom.
My ASIO buffer is set to 1024, my VEPro buffer set to 2 buffers (but even 0 or 4 doesn’t change much) and MIR at 2048.

So what you’re mainly saying is that I should split my setup and not only use one instance, but many? I currently have 8 Threads (hypothetically tho, as it is a true 4 Core and has virtually 8 Cores) assigned to the main instance, but maybe I should experiment more with multiple instances. I always preferred having one bad ass instance in which I can control EVERYTHING but maybe its not optimized for that. I’ll definitely try spreading my load better. Which would also force me to use MIR in Cubase, and mix in Cubase. My setup is mixing in VEPro, but it shouldn’t take too long to switch everything. (Even tho I personally prefer the VEPro mixer haha)

My Slave PC communication is definitely not the (main) problem. I already cleared those instances, deleted them, deleted the audio input plugins and the CPU was (then) at ±30% (10% gain mainly from the audio input plugins). It’s just the one master instance somehow.

As I said I’ll definitely try this approach, hopefully I’ll find time this weekend and give it a shot. Thanks again for your input!

Regards

[Zelorkq]

@Jalcide

You might try using the Windows’ Affinity feature to prevent Cubase from using one (or two) cores.

Do the same with VEP on the opposite cores.

http://www.techrepublic.com/blog/windows-and-office/change-the-processor-affinity-setting-in-windows-7-to-gain-a-performance-edge/

I haven’t test this with Cubase and VEP, but have with Cubase and Reaper and it works well in situations where ASIO performance leaves much of the CPU underutilized (almost all cases), and where another app could fit inside what’s left over, CPU-wise. The Affinity allocation prevents each app from stepping on the another’s toes and prevents Windows from re-assigning threads / cores at inopportune times (which for real-time audio, is always).

Thanks a lot for your reply as well Jalcide!

I can try fiddling around with the Affinity options, I’ve used those before, but with other programs.
But you said it leaves the CPU underutilized. Mine’s at 100% tho haha. According to the Task Manager all cores are very high on playback, and 4 are high and 4 are low when idling. But I’ll try changing a bit here and there, maybe it’ll help. Thanks man.

[Zelorkq]

@Indigo

I use VEP 5 with one master and two slaves. The master is i7 4770k/32g, the slaves i3770k/16g. Occasionally I even add my laptop to the network (also i7-based/16g.) I’m not experiencing the slowdowns you mentioned. I think it’s either a configuration issue (Cubase, VEP, Ethernet or Windows, for the record: I use 8.1) or an audio interface issue. I use RME UFX, but I’ve heard from a couple of people who use other devices (M-Audio in both cases) that they did encounter some problems with VEP.

Thanks for your reply Indigo!

Glad to hear you don’t have any issues. I don’t think it’s a device thing, because as I mentioned both my X-Fi Platinum and the Steinberg UR22 have the exact same amount of CPU throbbing, and they both use different drivers.
RME… I’d like to be able to afford one haha. Sometime in the future maybe

It’s most probably a configuration issue yeah. Are you using many instances of VEPro per server, or only one big instance?

I’ve got a few things I can try, maybe they will fix my problem. Thanks for your reply!

[Indigo]

@Zelorkq

Are you using many instances of VEPro per server, or only one big instance?

Many instances. I have templates that I load before I start working on something. These are orchestral mockups in 99% of the cases.

[Zelorkq]

@Indigo

@Zelorkq

Are you using many instances of VEPro per server, or only one big instance?

Many instances. I have templates that I load before I start working on something. These are orchestral mockups in 99% of the cases.

I also always load up my template/instances beforehand and also generally do orchestral mockups. However I use very few, but therefore huge instances… If time lends itself I’ll split my huge instance into multiple smaller ones, maybe that will help. Cheers.

[roel]

I noticed your post on the Vienna forum and there i could find some info.
http://community.vsl.co.at/forums/t/37957.aspx

So if it is correct your setup looks as follows:

master= cubase + VEP server (only 64 bit) + 1 instance (PLAY/VI Pro) + 1 instance Kontakt + MIR (as vsti or in VEP) + Vienna suite plugins
slave = VEP server (only 64 bit) + multiple kontakt instances

The audio from the slave is routed straightforward via the server to cubase, but then rerouted to the VEP environment in to MIR and SUITE.

Most of the vsti’s you mention are romplers so that is normally not the issue. But you are aware of the fact that kontakt and PLAY are also a Multi-core environments. (look for that topic in the VEP manual on page 15)
I also guess that every instrument that is loaded has its own output to the mixer in cubase.

There is nothing stated on the usage of the multitimbral instruments like play and kontakt. That can be important though. Imho try to use one kontakt vst for each preset of PLAY or KONTAKT and do not use the multitimbral functions of them. Otherwise kontakt and vep can be fighting for priority’s. Let VEP do the core handling.

Next thing i referred to (as were the other posters) is the fact that you have several tools for optimizing the setup.

1/ in the server window under options you can define the amount of threads per instance. Normally this should be as many threads for a single instance as possible, leaving one or two for the OS and cubase.

Less optimum, but imho better for analysis, is to assign a single thread to a single instance and then you can split things up and actually monitor in which thread the problem is caused, with cubase and OS taken into account, you can have up to 6 or 7.

To lower the strain in the problematic threads, you have a “buffer size” in the cubase track where your instance is appointed to. Since you have split up to multiple instances, each instance can be assigned its own buffer size. This gives you possibilities on how to control the strain on the entire system by differing the buffer size (per instance)

You can raise the buffer size for the problematic tracks, and keep the buffer size for live tracks down to 0 or 1. You want to be able to have a playable system.

So setup things this way should give you insight in how your system is and hopefully optimize things.

In my opinion, romplers do not cause any trouble. But you have some possible problems if the core handling is not correctly set up. At least there are kontakt and play in yoursetup that are multitimbral and possible multithreaded vsti’s on their won. Keep them one instrument for one outup in VEP, and let VEP handle the cores.

Do not throw everything in a single instance, since the resources that are assigned are in the above example only one thread per instance. Too much activity in one instance will easily kill the overall performance. Once the analysis is done, it is also advisable to rethink the way you will be working, and what will be loaded in what instance, to spread things over the system, taken into account the “threads per instance” assigned to the instance, and the buffer size that instance is being played.

Next probable issue could be the MIR and SUITE. Since you are close to the minimum specs for MIR, when taken into account that you also do play/kontakt/suite/cubase handling on the same machine, i guess lowering quality settings there (buffersize or other) can be possible todo’s here.

But that is something only you can determine.

A very nice way of trying to work around the issue is indeed to work with the affinity settings and reserving some cores exclusively for MIR/SUITE or by assigning threads for an instance that is only used for MIR/SUITE and raise the buffers for that Vienna ensemble instrument in cubase.

Hope this helps a bit.

kind regards,
R.

[Zelorkq]

Your description of my setup is almost correct. My outputs of each multitimbral instance stay in VEPro (master PC instance) and don’t go to Cubase. I mix solely in VEPro. However, I want to change that so that I mix mostly in Cubase and use MIR in Cubase and thus avoid Audio Input Plugins.

I am aware that Kontakt is multi-core’d. PLAY as well? Not sure…

@roel

Imho try to use one kontakt vst for each preset of PLAY or KONTAKT and do not use the multitimbral functions of them. Otherwise kontakt and vep can be fighting for priority’s. Let VEP do the core handling.

For PLAY I only use one output per instance (so singletimbral kind of), and one instrument but with many articulations, so that should be fine. You are saying I should use Kontakt as non-multitimbral? But doesn’t that remove its advantage? Wouldn’t I then only be able to load one instrument per instance?

I still want to split my VEPro instance into many instances and assign the correct threads. Haven’t tried that yet… I am definitely going to play around with the instances and buffer settings. Maybe even the affinity. Problem there would be that I would have to modify the affinity every single time I reopen the process…

Thanks a lot for your input. You mentioned a few things that I am definitely going to try to solve my problem


Regards

[roel]

ok
what i was suggesting is that when assigning a number of threads to the instance, it is also limiting the resources you have in the instance. Finding a balance is key here.
same story with too much “play” data on a single output but within a single instance.
i guess you are fiddling with it right now, so i wish you the best in finding “your” balance

kind regards,
R.

[beatpete]

I use VEP Pro5 with no problems (50+ midi channels and over 50 stereo outs) but I remember reading somewhere a while ago about limiting the midi ports (not channels) to 8, that they had a problem with more than 8.

[Zelorkq]

@beatpete

I use VEP Pro5 with no problems (50+ midi channels and 96 over 100 stereo outs) but I remember reading somewhere a while ago about limiting the midi ports (not channels) to 8, that they had a problem with more than 8.

That’s one of the reasons why I’m going to split my huge instance into multiple smaller ones. At the time I created my template, I hadn’t heard of that issue.

But as far as I know it’s not certain whether it’s a VEPro or Cubase issue. However, most other DAWs don’t even support as many MIDI ports as Cubase does

Thanks man

[cjadams]

Question… This 8 midi channel issue… what happens exactly?

At the moment i am putting almost all the articulations from Play into a a template across multiple machines. Yes setting that up is as much fun as you think it is. I have 4 instances inside of vepro server 64 inside each instance is 9 play plugins each with 9 articulations. This means 81 instrument-articulations per VEPRO instance. I might be able to get away with 3 or 4 full instances on any one slave. But will i run into that bug?
as way of example i then put midi channels 1-9 for each play plugin and route its audio back to Nuendo main 1/2 3/4 5/6 etc etc.:
Each articulation is sitting on a midi track in Nuendo with a corresponding audio return from Vepro.

Is this going to work using say 3 mac mini servers 2011 with fast Drives and 16 gig ram with Quad core i7s ?