VST Performance Spikes

Running Cubase 7.5 on Windows 8.1 on a desktop machine (lots of memory and a fast 4 core processor). Apart from anything MS has installed, Cubase is the only application on the machine.

MOTIF XS connected to PC via Firewire and onwards linked to a Yamaha N12. Have the latest Yamaha FW driver and the Cubase Extensions for MOTIF and N12.

The green “Average VST Performance” indicator barely shows 5% usage, however the blue “Real-time VST Performance” indicator frequently jumps suddenly to 100% and lights the red overload indicator. Just before this occurs there is an audio dropout. This usually lasts a second or less but can sometimes be as much as three or four seconds of silence.

It seems to happen when there is either a lot of MIDI data being sent to the MOTIF XS or when the resulting audio from the MOTIF exceeds the nominal 0dB on the mixer meter.

I’ve tried removing VSTs from the return audio from the MOTIF (eg compressor) and this reduces the number of times the blue real-time peaking occurs but it doesn’t prevent it.

By trial and error, I can reduce this peaking still further, but never get rid of it completely, by disabling “ASIO Guard” in the device setup and by increasing the sample size to greater than 2048 (which is unusable when you’re trying to record a MIDI performance").

Does anyone else have similar experience or am I missing something here. None of this occurred using C7 on Win 7 on a slower machine.

James

I’m presuming a newish computer as you mention an older one. First off I’d think a drive access bottleneck might be the cause if you’re streaming lots of data off it. Of course I can’t tell exactly.
What motherboard and processor?
You might also have missed some setup detail for your computer BIOS setting or a Windows Sound setting.
Could try switching the Priority in Cubase Devices menu. Or some driver may not be playing ball with Windows 8.
Just some suggestions but can’t be sure of anything really. When these things happen to me I usually find the solution is annoyingly simple.
I doubt this is Cubase itself though as usually you’ll find that any Cubase specific issues affect the program and the VSTIs in themselves and not the performance and are usually niggles, crashes and bugs rather than data breakup. Though someone else might think differently hopefully to solve this.

Jenks,

you are definitly not alone. These problems occur on specific systems and are well documented now.

Steinberg has given the following general reply on this issue:

viewtopic.php?f=196&t=53066&start=50 (and lots of others)

The graphic performance appears to be linked to the latest drivers’ implementation, with some of the improvements made for gaming and 3D graphics causing real-time spikes with particular plug-ins.
These plug-ins all share common characteristics - they over-ride the default behaviour of the pointer when hovering on the controls, so it might be related to a particular GUI framework.
I’m no developer, so I forwarded the outcome of my tests to the proper people in-house.

They were actually already on it and the GUI handling is being revised - it is quite unlikely that the drivers will be written the “old way” in the future, so it must adapt to the way drivers are working now and will probably work in the near future.

By the way, during my tests the behaviour of Cubase 7/7.5 and Cubase 6/6.5 was the same concerning this.
But Cubase 6/6.5 only shows the average VST Performance, so the spikes and fluctuations might look like a normal fluctuation due to the load, especially with a lot of plug-in instances or working at low latencies.
When looking at the Cubase 7/7.5 real-time meter, it might trick into thinking that the performance is much different, but the only way to directly compare the two versions is by comparing the average meter only.

Actually there are lots and lots of post about this issue on the forum. A good starting point is by using the search function on top of the forum and type “asio spikes” or “graphic performance” as search terms. You will find lots and lots of different findings.

Some have found a temporarily solution by rolling back the graphics driver to an older version. Some have confirmed that even changing a OS mouse scheme to an inverted setting can be a solutiong. Others have posted that a complete reinstall solved the issue. Also online you can find similar warnings when using specific graphic related software.

Some graphic card tools like Ati Power Play and Nvidia Powermizer interfere with real-time audio, since they prioritize the graphic card performance over other processes in the system. A solution there could be to disable or uninstall these tools.

Hope this sets you a little on track of the problem you have.
Maybe SB should make a more general posting about this issue, since this is rather frequently asked.

kind regards,
R.

Roel, thanks for the pointers! This gives me huge re-assurance.

I’m no developer either. I’d say I’m competent and not clueless with this stuff but by no means an expert. Having tried all manner of advice around this issue - a lot of it from this forum - I seemed to have hit the wall when I wrote the post.

Your words not only tell me I’m not alone (ie it’s probably not something I can cure) but also indicate that there is an awareness and “hope” for the future. So thanks again.

Since writing the original post I’ve done a bit more investigation using MS Windows 8.1 Performance Tools. I think I’ve tracked the issue down to Deferred Procedure Calls. I can correlate a spike in the DPC graph for the IEE 1394 i/f with the peaking of the real-time VST performance meter and the audio drop out. That is not to rule out that the real culprit is the graphics driver taking resources away from the things we (audio application users) need rather more than 3D graphics.

I’m stuck between a rock and hard place with the graphics driver as the first one that is Win 8.1 compatible is version I have. There is nothing for me to roll back to.

If the problem is the IEEE 1394 i/f after all (and it used to be in the Win 7 environment), then I can’t use the legacy version (which was the workaround in Win 7) because MS haven’t signed their own legacy drivers for Win 8.1 so you can’t load them.

I’ve now come to the conclusion that the only route open to me (for now) is to revert the new machine to Win 7 (probably using dual boot). That way I can use older graphics drivers and the legacy IEEE 1394 drivers. My old machine ran Win 7 and, although less powerful than the new beast, never exhibited these problems with C7.5.

Once again, thanks Roel for your post.

James