CPU overload when loading a project with specific VST's

[T0NIT0RMX]

Hello,

I'm having a CPU overload on remoteVstPlugin.exe when I try to load a project containing specific VST's.

Steps to reproduce :
I asked some people to reproduce it but it seems hard to reproduce, maybe it's not that noticeable on recent computers.

• Open LMMS 1.2.0-RC7
• Load DragonFly Reverb in the master
• Save the project
• Close LMMS
• Open LMMS 1.2.0-RC7
• Load the previously saved project
• Look at the CPU usage of the corresponding RemoteVstPlugin.exe

In my case, it's using 12% of my CPU...
It should use 0% when no note is playing.
When I play a note (with 3xosc) it jumps to 16%, which make LMMS almost unusable when I work on big projects with many more VST (Mequalizer, and all the free MELA plugin suite have the same behavior, and probably lots of other VST I use).

More infos
In LMMS 1.1.3 there was no problem, so I try bisecting is suggested by @DomClark
Here is what I found : a2cb7e9, which fixes a GUI glitch introduced the bug. (The commit just before doesn't have the bug)

My config
Windows 7 - 64bits

Hope these info will help come up with a solution. I understand that it may be related to the fact my computer is old (4 years old) but maybe there is still an explaination, because it was not there before. Or maybe a workaround to fix this ?

If you need more infos, or want me to try to compile some of your ideas, let me know, I'll reply ASAP !

Thanks in adance for your help,

[tresf]

I've attempted to reproduce using Windows 7 x64 and Dragonfly 64-bit using exact steps above and CPU stays at 0%.

I've tried all 3 VST embedding techniques (win32, qt and none) without any observable performance difference. I'm using SDL as my audio back-end.

[tresf]

On discord @T0NIT0RMX mentioned that a2cb7e9 was ruled out as the cause. If this is true, please update the description and subject accordingly.

[tresf]

Update: @justnope had theorized that this was OpenGL/driver related, so I tried disabling hardware acceleration altogether but the RemoteVstPlugin.exe still hovers at 0%. I can't reproduce this bug on virtual hardware.

[tresf]

Using process explorer procexp64.exe, I was able to do a before/after of 1.1.3 and 1.2.0-RC7 and the RemoteVstPlugin.exe utilized CPU on fresh open of a project while sitting at idle is within 1/100th of a percent from each other. I'm inclined to call this issue system-specific unless proved otherwise. Removing bug label.

[tresf]

@T0NIT0RMX thanks for allowing me to look at the machine. We found that the offending machine gets stuck in ig75icd64.dll!DrvValidateVersion which Qt has a documented bug #QTBUG-60216 for without any direct solution. There several reports online mentioning this and they all seem to have the Intel HD 4600 driver in common.

The temporary workaround (for now) is to turn off Aero on the desktop, which inadvertently fixes this issue.

We tried many (many) things including:

• QT_OPENGL=software|angle (no effect)
• QT_ANGLE_PLATFORM=d3d11|d3d9|warp (no effect)

I believe these environment variables are either not being picked up by RemoteVstPlugin.exe or the VST with the issue isn't benefiting from this.

Some workarounds...

• Disable VST embedding altogether
  • Makes LMMS very difficult to use, plugins are always on top
• Disable desktop compositioning
  • When Aero is disabled, the issue goes away
• Show and hide the plugin at least once
  • Can be coded as a workaround but not ideal

@T0NIT0RMX attempted to use the "Compatibility" area on the LMMS shortcut to disable the desktop compositions but it doesn't appear to actually work nor influence anything.

Edit: Here's a script that can automate the disabling of Aero...

@echo off
net session >nul 2>&1
if %errorLevel% == 0 (
   echo Administrator detected
) else (
   color 0C
   echo Please run as admin
   echo.
   pause
   exit 1
)


net stop uxsms
start "" /d "%programfiles%\LMMS" /wait "%programfiles%\LMMS\lmms.exe"
net start uxsms

I'll leave this bug open for a bit incase this new information uncovers something that can be done in code.

[T0NIT0RMX]

Thanks for the clarifications @tresf , so I think you can remove the "need clarification" label, because now we know the causes.
You can also remove the 1.2.0 milestone !
Thanks again for the help you guys gave me to deal with this issue.

[DomClark]

the offending machine gets stuck in ig75icd64.dll!DrvValidateVersion

It's unlikely this is the actual method it gets stuck in; unless you have full debug symbols for ig75icd64.dll, tools like that generally just show the first exported symbol that appears before the current code position. Also, that column just shows the starting address of the thread - to find out where things are actually stuck, you can double-click on the thread to see the full stack.

I believe these environment variables are either not being picked up by RemoteVstPlugin.exe or the VST with the issue isn't benefiting from this.

RemoteVstPlugin doesn't use Qt in general (only on Windows, where Qt is used for the shared memory, IIRC), so those environment variables probably aren't going to mean anything to it.

• Disable VST embedding altogether
  • Makes LMMS very difficult to use, plugins are always on top

The plugins are always on top by Umcaruje's request in #4110 (comment), implemented in fcc883f. If this is annoying, we may want to revisit it.

It sounds to me like the issue is a driver bug; OpenGL driver support is notoriously flaky on Windows, which is probably why the Qt issue is fixed by using ANGLE, which translates OpenGL to Direct3D.

[tresf]

The plugins are always on top by Umcaruje's request in #4110 (comment), implemented in fcc883f. If this is annoying, we may want to revisit it.

Poll opened #4802

It sounds to me like the issue is a driver bug; OpenGL driver support is notoriously flaky on Windows, which is probably why the Qt issue is fixed by using ANGLE, which translates OpenGL to Direct3D.

The drivers were updated with no impact to system performance. I was starting to hypothesize that it's some even stranger such as a lingering driver version on the machine or a problem that was specific to the laptop's dual-display-adapter (one NVIDIA, one Intel). One of the similar (internet) issues I stumbled upon offered teh explanation as being caused by buffering to a non-primary monitor; both theories are just speculation :)

to find out where things are actually stuck, you can double-click on the thread to see the full stack.

@T0NIT0RMX should be able to provide this information. Even if we can't fix it, the issue seems to plague enough Intel HD 4600 cards that it would be valuable to document publicly.

[T0NIT0RMX]

@tresf @DomClark Sure ! here it is when I double clcik on ig75icd64.dll!DrvValidateVersion

*ntoskrnl.exe!KiCpuId+0xaa
*ntoskrnl.exe!KeReleaseSpinLock+0x612
*ntoskrnl.exe!KeWaitForMutexObject+0x1a3
*ntoskrnl.exe!KeQueryActiveProcessorCountEx+0x218
*ntoskrnl.exe!RtlNumberOfSetBitsUlongPtr+0x10cd
*ntoskrnl.exe!KeReleaseSpinLock+0x81d
*ntoskrnl.exe!KeWaitForMutexObject+0x1a3
*ntoskrnl.exe!ExReleaseSpinLockExclusiveFromDpcLevel+0x4bf
*ntoskrnl.exe!SeLockSubjectContext+0xa6
*ntoskrnl.exe!ObOpenObjectByPointer+0x43e
*ntoskrnl.exe!ObInsertObject+0x5c9
*ntoskrnl.exe!NtConnectPort+0x41
*ntoskrnl.exe!longjmp+0x5b93
*ntdll.dll!NtConnectPort+0xa
*dwmapi.dll!Ordinal132+0x87c
*dwmapi.dll!Ordinal132+0x9b1
*dwmapi.dll!DwmSetWindowAttribute+0x2cc
*dwmapi.dll!DwmFlush+0x92
*ig75icd64.dll!DrvValidateVersion+0x139a
*kernel32.dll!BaseThreadInitThunk+0xd
*ntdll.dll!RtlUserThreadStart+0x1d

[michaelwillis]

@T0NIT0RMX Which version of Dragonfly Reverb are you using? Some versions of Dragonfly have had bugs that cause high cpu usage.