Voice attack with HCS voice packs, slow macro execution

[Designated_david]

I have an issue with Voice Attack in general, and the only thing I use it with is Elite, and with HCS voice packs. So I've been on medical leave for a few weeks, (5/14-6/17) and haven't had much opportunity to play, and have also been away from my apartment, so I haven't had access to the computer. When I left, Elite and Voice Attack with HCS voice packs were working just fine, with no appreciable lag or hesitation in response, and all the macro keystrokes were occurring at a reasonable pace. Upon my return, it's operating like a herd of turtles through a field of peanut butter. Elite did have a patch while I was gone.

My keystroke speeds and panel operating speeds are set very low for quick responses as a diagnostic step. Additional profiles were all removed, and Singularity and EDDI were re-imported. There are only two profiles. Singularity, and EDDI, and Singularity has been set up to include commands from EDDI. I have "active window" targeted in voice attack, instead of the ED client specifically. I know from previous diagnostic steps that this is a way to get faster keystrokes out of it (I don't know why).

I have even tried removing all voice packs, and HCS tools, and reinstalling one, as well as re-downloading the HCS tools portion as a standalone zip file. I've also tried reinstalling voice attack.  At the time, i was running 1.7.5, then updated to a beta, then a later beta, then finally to 1.7.6.  Someone else suggested that 1.7.3 works great before recent updates, but I cannot roll back to 1.7.3 because the Singularity profile takes advantage of features and updates found in 1.7.5 and later. 

No matter how quick I've got the keyboard settings set, the keystrokes in the macros feel like someone's hunting and pecking for them. I've been trying to search around the internet the past weeks to find out of anyone else is having this issue, but I haven't found much on the topic, so sorry if this is a re-post.

I originally posted a similar message on the HCS forum, but with no luck.  They are looking into timings with the next profile update, but I really hadn't heard back much from them. 

I have the keyboard timings adjusted to some very low values indeed. Key is pressed for 0.05, pause when opening panels is 0.65, pause between key presses is 0.03, down from 0.06, and pause between GUI presses is 0.03, also down from 0.06. Again, nothing has changed from when it was working to the time that I got back and started this all up again, notwithstanding my troubleshooting steps. It still feels like there's almost a full second between each keystroke or UI change. Not to mention a delay of almost 2-3 seconds between the command being completed, and the voice response, and the voice response to the macro execution.

Voice attack recognition delay is set to 0.

Specs: 
CPU:  Intel 3930K, OC'd stable at 4.4GHz and 1.315V
Cooler:  Corsair H150i, and lots of case fans.
RAM:  G-Skill DDR3 1600MHz 32GB, quad channel
MB:  Asus Sabertooth X79
Audio:  SB Recon3D Champion with I/O Drive.
Network:  Onboard gigabit LAN, wired.
Storage:  2x Samsung 850 EVO 1TB SSD's in a RAID 0 configuration, 2x WD Caviar Black 750GB 7200RPM HDD's in a RAID 0 configuration
PSU:  Corsair RM1000i
Peripherals: Corsair K95 RGB, Corsair Dark Core RGB Mouse, Thrustmaster T16000M FCS Flight pack with rudder pedals
Display: Samsung U28E590 4K display on display Port, Samsung SMBX2331 at 1080P on HDMI
OS: Windows 10 64-bit, build 1903
Video drivers: 430.86 from May 27, 2019
Elite Dangerous is up to date
Voice Attack was 1.7.6, running as administrator
EDDI v3.4.1
HCS Tools v1.0.5 with plugins version 3.1.2
Singularity 2.1.1

Finally, the link to the private youtube video demonstrating these issues, and was specifically made for the HCS guys to look at, but you can at least see what's going on.  Sorry for the low volume, I'm still tweaking settings for OBS.

https://youtu.be/_TfbGiJHTZI

Thanks in advance, and have a great day! 

[Pfeil]

Have you tried disabling plugins, creating a new (non-HCS) profile, adding a command that just sends a keypress, and checking what the delay is?

[Nazdakka]

I'm also seeing this, and I've done a test (although not the full debugging loop that David has). Comparing a dummy profile and the full HCS profile, the dummy is noticably snappier (I did not unload plugins, as my dummy profile was faster even without doing so). The delay comes between VA recognising the command (and it appearing in its window) and the key being pressed.

[Gary]

There could be two different delays.  The first is when you speak a command into your mic and VoiceAttack reacts after a certain amount of time.  You'll say, for instance, 'fire weapons'.  There will be the usual delay and then VA will say, 'Recognized: fire weapons'.  The second delay is between when VA says, 'Recognized: fire weapons' and when something actually happens in your game.

For the first type of delay, you'll want to take a look at this thread, as this is almost always the culprit - especially if things were fine and now they're not (ignore the title):

https://forum.voiceattack.com/smf/index.php?topic=64.0

Other things that can factor into the first kind of delay is noise - that could be ambient or line noise.  Noise WILL kill speech engine performance.  There is a long read on that over here:  https://forum.voiceattack.com/smf/index.php?topic=1635.0


For the second type of delay, that could be any number of factors.  One that comes to mind first is in regards to targeting.  If you've got something set in you main screen's, 'target' box other than, 'Active Window' (for instance the Elite client), you may have delays as VA tries to find your target.  Again, this is just an example.  You'll probably want to talk to HCS about delays at that point.

Creating a new profile and testing out some commands is a good place to start (as indicated and tried).

Hope some of that helps!

[Nazdakka]

It seems like it's the second for me (I always target 'Active Window' so it's not that fix). VA gets the command fast and works as normal, there's a pause between the command being recognised and it being executed.

Seems noticably worse since recent updates. Could this be one of those problems where changes to both programs have resulted in a different, less optimised, VA code path being exercised?

Thread in the HCS forum, for reference: http://forum.hcsvoicepacks.com/forum/technical-support/27804-elite-dangerous-singularity-extremely-slow-keystrokes-and-laggy-response-time

[Gary]

Are you running with any other plugins enabled by chance?

[Designated_david]

Thank you all for the quick replies...

I have "Active Window" as the target.  Always have.  I've known for a long time that it causes problems to target Elite directly.  Doin't know why, it seems counter-intuitive. 

I've done a redux to my windows speech profile already. 

There's a 0.25-0.5 second delay between the command being spoken, and being recognized, a fair and acceptable delay, and that's not the issue.  There is a longer delay than normal between the command being recognized and the attached macro being executed.  And the steps and delays of that macro being executed are far from what is set in the HCS customiser.  That's where the issue was.  I left on medical leave and everything was working great, and when I came back, Elite was patched, I updated Windows to 1903, and now it doesn't work.  All other updates to VA and HCS packs were done after this was discovered. 

The only thing I haven't tried yet is to make a dummy profile and test command execution without it.  If it's fast, then we know the issue is with HCS's product somewhere. 

[Nazdakka]

Only HCS plugin 3.1.2

(My VA version v1.7.6)

[Designated_david]

The only two plugins, and I've tried disabling one of them for diagnostics, are the HCS tools, and EDDI.  I had disabled EDDI for troubleshooting.  To run VA with HCS, the HCS plugin is required.  Otherwise the voice packs don't work.  Disabling EDDI didn't make a difference.

[Gary]

I'm not sure what commands are within those packs, so I don't know exactly what it is that they are doing.  Is it possible to coordinate with HCS to try to pin down a command that does something very simple yet exhibits the same behavior?

I'm reviewing the area of code that would potentially be affected - I'm not finding anything between 1.7.2 and 1.7.6 that would make a speed difference.


Edit - Do the commands play sounds?

[Nazdakka]

I'm not sure what commands are within those packs, so I don't know exactly what it is that they are doing.  Is it possible to coordinate with HCS to try to pin down a command that does something very simple yet exhibits the same behavior?

I mean, it's pretty much all of them. 'Close map' and 'lower landing gear' are the ones I've been using, setting focus to Notepad++ so it is the active window and records the key press. HCS lock the commands in the profiles so it's hard to see exactly what's going on inside, but I suspect from the amount of code in the profiles that every voice command involves several profile entries chained together.

Edit - Do the commands play sounds?

Yes. The sound fires at the same time as the keypress does, after the delay. I'm trying to sort out a way of recording video of what I see, but the delay between the command appearing in the log and the keypress firing is usually 1.5-2s.

[Designated_david]

Yeah...  About that test profile... MUUUUCH faster! 

The commands I use to test this have been power transfer commands, moving pips around.  That should basically consist of a check to see where they already are, and a series of keystrokes to balance, then redistribute. 

Problem's DEFINITELY with HCS--I hate to say it. 

"The more they over-engineer the plumbing, the easier it is to stop up the drain."  -Montgomery Scott, Star Trek III

[TheThingIs]

we are looking into this but we are not seeing the delay you guys are talking about. Some commands do tap into the Elite journal files for info which can add a 0.5s delay but nothing more

[Gary]

In regards to the sounds, if you go to Options > Audio, what do each of you have selected as the output type (top-left)?
If you have Windows Media components selected, try changing to integrated components (and vice-versa).

Key presses will not cause a delay - that's all api calls and it's been around for 12+ years.

The only other thing would be OS file system i/o.  You'd maybe want to try some commands that do not access the journal to see if that makes a difference.

[Nazdakka]

Audio Output Type for me was set to 'Windows Media Components'. Switching to 'Integrated Components' is much better, and seems to entirely fix the problem. Thanks very much!

A few more observations that might help your debugging:

With the audio output type set to 'Windows Media Components', there's a noticable burst of CPU activity during the pause from a process called 'Windows Audio Device Graph Isolation'. It goes from a background of 1% to 15-20% for the length of the pause, and now I'm listening for it, I can actually hear the CPU fan spin up during this period.

The journal isn't related to anything; I got the pause (with the old setting) even when feeding the parrot or talking to the ship's cat (which presumably don't use the journal).

I'm on Windows 10 Version 10.0.17134 Build 17134. My CPU is an i5-4960K running at 3.50GHz, ASUS Z97-K motherboard, 16GB RAM. My video card is a GTX 970.

[Nazdakka]

Aside: The thing with keypresses was because the HCS packs send commands to Elite by generating key press events; if I used my voice to trigger an HCS command with Notepad++ as the active window, that keypress ends up in Notepad instead of Elite, so I can identify exactly when the command has fired.

[Gary]

If changing from Windows Media Components to Integrated components has made things faster, then you've got something borked up in your setup (there are lots and lots of folks that are actually still using that setting).  You may want  to do a system file scan just to check things out: 

https://support.microsoft.com/en-us/help/4026529/windows-10-using-system-file-checker


It's not a guarantee that it will find/fix your setup, however, it may - it's also good to do this from time to time to make sure things are square.

Thanks for the info!

[TheThingIs]

I've tested with Windows media components selected and everything is still working fine on my end. I'm glad it has solved the issue for you but it's still an issue I can't replicate yet.

[Nazdakka]

If changing from Windows Media Components to Integrated components has made things faster, then you've got something borked up in your setup (there are lots and lots of folks that are actually still using that setting).  You may want  to do a system file scan just to check things out: 

https://support.microsoft.com/en-us/help/4026529/windows-10-using-system-file-checker


It's not a guarantee that it will find/fix your setup, however, it may - it's also good to do this from time to time to make sure things are square.

Thanks for the info!

Thanks, I didn't know that command. I ran it and found nothing.

One piece of speculation: I have a set of Corsair wireless headphones that require some supplied management software (iCUE). It's something slightly unusual in my setup that's in at least the right general area, so maybe that has messed things up... somehow?

I've tested with Windows media components selected and everything is still working fine on my end. I'm glad it has solved the issue for you but it's still an issue I can't replicate yet.

I'm not sure what I can offer... I mean, Remote Desktop, maybe?

[Designated_david]

SOLVED, for me anyway.  Updated VA to version 1.7.7, HCS Plugins to 3.3.1, and Singularity profile to 2.2.1, and everything is a healthy kind of snappy.  Your last updates seemed to have fixed the slow macro execution.  Not only is it usable again, but would be fast enough to stream with high overhead use. 

Gary, thanks to you and your team, and the collaboration with the HCS team in getting this worked out.  I know other users may still have issues related to other things, but the changes you made in the most recent patch have solved my issues. 

Thanks again, and enjoy the rest of your weekend! 

Keep up the great work!

[TheThingIs]

glad it's solved for you but it is quite odd...the latest beta not 1.7.7 has the fixes in for this and the profiles only got a very minor change to gui presses. Essentially the pause between keypresses is only needed when pressing the same key again so I put some code in to only add the pause if the previous key was the same as the one I'm about to press. Oh and one other thing where I forced the profile to target active window regardless of the target box on the main VA window