Feature: Remote Keypresses

[NeverListens]

First off, I sympathize with you being the developer of a program used by the public. (Not from personal experience though) I don't expect you to implement this soon, or at all, just because I suggest it.

I have tried several different "Voice Activated Commands" programs, and always have the same problems when running it with some games (especially Jane's FA-18). I have changed priority of the VA programs, the SAPI engine, the game, etc. I can eventually get it to work with little delay, but then Voice Recognition is starved for CPU cycles still. Using VAC instead of others helps best too. (Not a suck-up, just a fact)

Its not the game itself, as Ive made a C# program to read the input of my XBox controller (I forget the name of the driver at the moment) and send keypresses to the active window -- Makes a great addition to my lowly MS Sidewinder -- and that runs without delay (and I made it quick and sloppy for my own needs; no optimizing).

The best option would be to have the Voice Recognition done on a computer other than the one you are playing the game on.

Before I disect my C# program to make it into a client/server for my personal needs (capturing keypresses and sending it via TCP to a cilent version). I was wondering if you would consider adding it to VAC. I'm sure you would make a cleaner, more optimized implementaion than I. (Stress really ruins concentration)

Adding what? The ability to send TCP messaes to a "VACC" (last C for client) that would simulate keypresses where the VACC is running rather than the VAC computer. Obviously this would be an option.

The VACC would only need to listen for a connection, accept a login (for security), and then simulate keypress based on incomming data.

As for the main prog, If "Remote keypresses" is activated (and a address, login and password specified) every point where VAC would normally simulate a keypress, it would send a message to the client.

The first implementation could be a oneway connection VAC->VACC, then with later implementations, keypress at the VACC computer (for turning VA off/on, etc) could be sent back to the main program.

I'm sure this would be at the bottom of you list of TODOs -- provided you even consider the idea -- and I'd probably hack together something for myself in the mean time. However, there are probably others out there that would like to see this feature one day. (a way to split CPU cycles 'tween VA and gaming)

Anyway, a good program. Keep up the good work. And thank you for listening.

(Pardon the disorder of the post. Everyone has stress in their life, however, mine is affecting my concentration/etc)

[Shift_E]

Hello NeverListens,

Is that no one ever listens to you or do you not listen to anyone?

I’m in no way disagreeing with you or saying no way; I’m just sharing my thoughts about your idea.

I’m not really convinced running voice recognition on another computer is the answer to off load CPU processing for programs or games that use a high amount of CPU. Adding another layer on the client to handle remote input, I believe would negate the expected gain. Right now VAC uses between 2% to 4% CPU and around 40 megs when processing a command, which is not resource intensive. I use Silent Hunter III, which uses a lot of CPU and experience delays when issuing commands using the keyboard, I don’t anything will help for these games. The sound card is another thought, it does most the work and if the sound card is being robbed of processing cycles or over loaded, that will cause delays for voice recognition. If you look at your graphics PCI latency you’ll see it is set to 256 and to should be set to 32-64, which makes it almost impossible for your sound card to complete all it’s assigned processing and produces stuttering and sound static.

Having shared my thoughts and sounding negative, I’ll have a look at remote processing and see how involved/possible it would be.

[NeverListens]

Since this is about Voice Recognition, "NeverListens" is a joke on that. (Often, I choose usernames that are parodies of the subject or name, ie "ChronosTube" = TitanTV.com)

I understand and respect your thought. I reply not so much to change your mind as I do to... Well, reply.

You are right, VAC uses very little CPU power. However the, SAPI engine (I think that is the file. I had HD problems and am just reinstalling after a couple months) can use up a lot for the cycles at times -- depending on the phrase spoken, and possibly dependant on the number of phrases its considering (didn't test that last part).

Actual keyboard input (me typing) experiences no delay at all in the relevant games. Once the VA program (VAC, Shoot, and others) chimes recognition after a short to long pause the keys are entered immediately with immediate effect in the game. I've even watched TaskManager (or it was processexplorer) while the game was in background, and saw that the speech recognition engine is what saw a spike in CPU usage, not the VA program.

PCI latency. Before I had to reinstall, I turned most devices down to their minimum recomended settings. (It slightly mproved the DX3d delay I saw in Half-Life and Morrowind [changing the "render ahead" settings helped most though]).

I started playing around with my jaloppi of a program, Happy_Stick, and quickly/easily added key capturing. I think I will even have the JoyStick attached to the other computer as well; Just "Search&Replace" all keybd_events with a routine to do a local keybd_event or send a TCP message to a client.

So... I should be able to get a make-shift solution for myself quickly.

I can't say I definately would find time, inspiration, or clarity of thought to work on it... However, if I were to make a DLL (clean programing, good code documentation, optimized, etc) and client in C/C++ (what I imagine you use) would you be interested in supporting it as an optional addon.

Maybe I'm missing something, but as I started adding it to my frankenstein-of-a-program (think quickly hacked PERL in c#) it seemed less involved than I thought it would be. So I shoudn't have too much troulbe.

You'd tell me what type of params the DLL functions should support, etc. What standards it should support. When done, I give you the source code. Since its a DLL, I'd never need to see your source.

Say, thats an idea for VAC. Addon support. Coded in a way that the only overhead is seen If/when addons are actually used. I haven't an LCD (3in screen that show temp/time/rpms), but someone might want to code a DLL addon to display VAC info on it.

Since it seems I can slap together a "keypresses bridge" for myself in a more efficient maner than I thought, I seem to be fine. However, if you think that somewhere out there a non-programming user might want to split it (CPU load) up, I could put the DLL and client on a list of TODOs.

Anyway, thank you very much for listening and especially for responding -- quickly even.

[Shift_E]

You are right, VAC uses very little CPU power. However the, SAPI engine (I think that is the file. I had HD problems and am just reinstalling after a couple months) can use up a lot for the cycles at times -- depending on the phrase spoken, and possibly dependant on the number of phrases its considering (didn't test that last part).

Using 2%-4% CPU and 40 megs was counting VAC and SAPI. If the voice recognition is slow then you need to adjust some settings in the properties. The longer the phrase the quicker the recognition is.

I looked into sending key command to a remote computer and I see a couple of problems with the idea. First is the client and server machines will have to listen for events verses triggered events. This alone will cause delays in sending the key commands. The second problem would be watching the client for keystrokes; this would be a huge security risk on the client machine.

You can test the speed issue out by writing an application to send key commands on the server and one to receive the commands in the client. I don’t think it would matter much if you used UDP, TCPIP or Winsock, the speed should be about the same.

Here’s a start in C# using UDP:

private void SendMsg(string aMsg) {
using (UDPClient xClient = new UDPClient()) {
xClient.Host = textHost.Text.Trim();
xClient.Port = 6001;
xClient.Send(aMsg);
}
}

Bottom line is, I truely don’t think you’ll gain enough off loading VAC and SAPI to justify the effort. If I had thousands of requests, then I’d more than likely do it anyway.