ASIO peak via mouse (PLAY issue?)

Cubase
1

Hi all,

I have a small problem in my template setup, I hope somebody can help.

My Cubase 7.5 project has VEPro connected with 4 instances, 2 of which have PLAY instruments (amongst others, VSL & Kontakt) in them and two have only VSL.

Now my ASIO realtime meter is running at about 25% when idling, not as good as I’d want it, but that’s not the subject of this thread. My problem is that I get 100% asio peaking when moving my mouse in certain scenarios (even if I’m only playing one instrument):

I get the peaking (and thus crackling) when my mouse cursor moves from window to window (eg. mixer to key editor, but NOT within a window) and the worst is when my mouse moves over my MIDI track names (I have a big template with many tracks). Going up and down with the cursor over the names is insanely crackled and the gauge under F12 is jumping up and down like mad … :frowning:

Now weirdly enough, when I disconnect my VEPro instances that contain PLAY, the peaking stops when moving my mouse. If I delete my PLAY instruments and keep only Kontakt & VSL, no problem as well.

I have no idea if PLAY is the culprit… I hope not :wink:

Has anyone ever had these type of problems before? I’ve seen a few mouse issues before, but they seemed to have a different nature.

I’m using Asio4All 2.12 drivers (2.11 same thing).

Thanks in advance.


Regards

2

Yes, there are reports for this.
The culprit is the graphics driver in most cases and when hovering your mouse over GUI-elements that have dynamic content in it, is seems te cause ASIO spikes.

There are ways to get rid of this:

1/ odd but true: change your mouse-scheme in windows to the “inverted” scheme.
howto?: Change mouse settings - Microsoft Support

2/rolling back to an older graphics driver version (when you did not have the problem) and keep those untill the issue appeared solved it on some systems.

howto: Windows help & learning

If you look around on this forum and use the search function, type in “ASIO”, “spikes” and “PLAY”, then you will find a lot about this topic, as SB responses too. This issue is known, but system specific (operating system), so this is not easy to find a definitive solution for it i guess.

kind regards,
R.

3

Thanks for your reply!

The mouse had absolutely no effect, didn’t help. But the culprit was the graphics drivers. I actually did the opposite and installed the latest ones and now things seem to be fixed.
I find it odd that the graphics drivers cause such peaks, but only if PLAY is in the VEPro instance… whatever :smiley:

Thanks for your help :slight_smile:

4

Technically it happens when the code which executes the dynamic response to mouse movements is not decoupled enough from the interrupt.

Usually a sign of a terrible driver developer.

5

Well developing drivers isn’t the easiest of tasks :wink: especially when considering cross-compatibility between many devices and software.

Not sure what actually fixed it now. Did they maybe implement better interrupt handling? Whatever it was, the latest version seems to be fine :slight_smile:

6

Indeed this is an issue - from my experimentation in another thread, I solved this by doing the following (I have an AMD card):

–Download driver package 12.1. You can do this from the AMD site by choosing your hardware and OS, but then when presented with the most recent driver, instead click on “Previous Drivers and Software” in the bar on the right. I chose the oldest one, v12.1 built on 1/25/2012.

–Completely uninstall all current AMD drivers and software. On windows, do this through Control Panel:
http://support.amd.com/en-us/kb-article … ivers.aspx

–Reboot.

–Install the package you downloaded in the first step. I did NOT install Catalyst Control Center NOR any of the video transcoding options.

–Reboot again.

The process is similar with other video card vendors - you want to find an older driver. For some reason it’s drivers within the past 24 months that seems to cause issues.

Steinberg is aware of this.

Full thread here:

7

Weird then that the latest has fixed the issue on my side… (AMD user, I just updated to the 14.9 package)
But heck, if it pops up again, I’ll try reverting back to older drivers.

Seeing that Steinberg is aware of this, maybe things will be alright in the future :slight_smile: