Mic Resetting To 100% Input Level When Mce Runs

[KingGhidorah 209]

FS++,

 

As you might recall, I have suffered from horrible Vox Script lags, for as long as I've had MCE.  I recently changed some things around and noticed that my microphone was set at 100% input level.  I don't know if this was always the cause of the voxscript lags, but in this case, all that spurious background noise it was picking up, especially on the noisy Q400 and NGX, was causing MCE to flail, and the scripts were lagging badly.  A retune of the microphone to 25% magically rectified the issue.

 

Inevitably the Voxscripts lags always return.  What I was able to determine is that after every run of MCE, when I go back to the control-panels, microphone input sound levels page, that my Mic is set back to 100%.  After I start MCE, in order to avoid the laggies, I have to bring the sound page up again and set it back to 25%, and then the voxscript flows have been working as they should.

 

I have MicTuneOnStartup set to Zero.  I don't want to have to retune the mic every time.  But it certainly appears that just the act of starting MCE up is retuning me to 100% anyway.

 

Why is this happening?  Is it some setting in Windows, or is it MCE doing an input sound level reset?  How do I get my mic input levels to just stay at the correct tuning, forever? 

[KingGhidorah 209]

Here is an interesting update on the issue.  When I went to the control panel advanced microphone tuning page, where you do the "Setup Microphone" wizard, I practically yelled into the microphone to get Windows to automatically set the level at 21%.  After finishing the Wizard, I manually reset the microphone input level to 50%, and hit OK.

 

I started MCE and did a few things and then shut back down.

 

Guess where the Microphone input level was after shutting down MCE?  21%

 

So, is this just a Windows bug, and I'm going to be forced to "fool" the microphone setup like that, or is there something that MCE is doing to cause the resetting of Mic input levels to the settings the Wizard originally chose?

 

FYI, I'm not using a fancy headset.  I'm using a noise cancelling clip-on interview mic that sits nestled up against my throat, and appears to work great as long as I can manage to tune the settings and most importantly, get them to stick.

[FS++ 708]

Interesting...

 

No, we don't adjust the mike gain programmatically.

 

Surprised just as you are. It's possible, when one triggers the mike tune wizard, the latter initially sets the gain to 100% then slowly reduces it as the user starts speaking.

 

I assume you don't have another audio based app running in the background like MSN chat or Skype.

[KingGhidorah 209]

No other audio stuff running.  After experimenting on 3 different airplanes (NGX, DC-9, Q400) yesterday for hours, I'm almost certain that this apparent Win 7 behavior was the big cause of those persistent voxscript lags:  The gain levels being set by the Tuning Wizard, which resist manual change via the mic slider, were just too high.  Now that I've fooled the Wizard into setting the gain low, NGX and DC-9 are lag free.  The Q400, at my chosen speaker volume, still gave me a few minor lags in my experiments, but I know it is a matter of interference, because when I hit "q" to mute the engine sound, the Voxscripts all proceed without a hitch.  Would it be possible in the long term to consider adding an "input mute on" and "input mute off" command line option for the Voxscripts where we could selectively deal with certain noisy situations (like After takeoff) by just turning the FO's ears off for a short while? It would seem that in a noisy enviorment, certain commands seem to be more prone to hangups than others. For Example:

 

[sCRIPT]

Input Mute On  <------------------------------------------hypothetical

both condition levers to climb

pause=2

Notify=props for climb

fuel pump tank one off

fuel pump tank two off

disarm autofeather

Input Mute Off <---------------------------------------hypothetical

both bleeds on

yaw damper on...

....

...

[charlie130 196]

I can add a twopenneth to this topic.

 

I see my Windows 7 inexplicably alters the microphone gain, intermittently.

 

This is only 10% at most, so does not affect the running of MCE by causing extraneous sounds to be picked up by the speech engine. However its always a lowering of the microphone sensitivity, so my voice becomes harder to hear on recording using FRAPS.

 

I only use the microphone in MCE and in a Corel editor, so could be the editor and Windows 7 that's causing the microphone setting to be altered.

 

Like I say, this does not affect the speech recognition or MCE running in any way. It appears that Windows adjusts the microphone level without instructions from the user? 

 

I blame a gremlin in Windows for this!

 

All I do is check the Windows microphone gain setting each time I boot up and ensure its set at the desired level. Thereafter it stays at the setting during the session.

 

Cheers

David.

[KingGhidorah 209]

Since background engine and fan noise seems to be the leading candidate (at least for me) as the cause of Voxscript lags, what does this mean?  When MCE picks up things like engine or recirc fan sounds, it spawns an unlimited number of new threads?  Strangely, this unwanted processing of background noise does not appear to have any deleterious effects on it's ability to process direct commands.  Those work nearly to perfection for me.  In the absence of a perfect microphone, perfectly tuned, I wish that there was some way that the software could learn to ignore or filter out the engine sounds without causing the program to thrash, even if it hears them. 

[FS++ 708]

Since background engine and fan noise seems to be the leading candidate (at least for me) as the cause of Voxscript lags, what does this mean?  When MCE picks up things like engine or recirc fan sounds, it spawns an unlimited number of new threads?  Strangely, this unwanted processing of background noise does not appear to have any deleterious effects on it's ability to process direct commands.  Those work nearly to perfection for me.  In the absence of a perfect microphone, perfectly tuned, I wish that there was some way that the software could learn to ignore or filter out the engine sounds without causing the program to thrash, even if it hears them. 

 

Since your speech profile is trained against an almost silent background, it won't perform as expected when engine sounds are coming out of speakers.

 

Try positioning speakers in such a way that they don't feed directly into the mike.

 

Another option is to create a brand new speech profile, make it active, and train it from scratch under those same simming sessions conditions.

 

Record a couple of minutes of the typical ambient noise you experience during your sessions, say on your cell phone or tablet.

 

Play that pre-recorded audio in a loop, all while training the new speech profile. The new profile will become aware of the background noise and should perform better.

 

MCE only spawns a single thread per command. The reason you may see more is because the speech engine is running inside the "mce.exe" process. The latter creates its own threads, some of them real time priority threads going full steam when recognition is taking place. Thankfully, only for short amounts of time. Bursts, rather than continuous CPU usage.

 

 

And this is what happens when the speech profile is out of synch with ambient noise conditions :-))

 

http://www.youtube.com/watch?v=2Y_Jp6PxsSQ

[KingGhidorah 209]

I'm definitely not having the problems seen in that video.  The recognition engine seems to be responding perfectly to my direct commands.  Misinterpreted commands are very rare.  It is not hearing the ambient noise environment and ever making the mistake of interpreting that as an actual command, so I'm not quite sure why the VoxScript commands are actually being interfered with, if it (correctly) isn't interpreting this background noise as an actual command.  Does that mean that my proposed "Input Mute" within a script would make no difference anyway?

 

Would you agree that it is possible for an overboosted mic picking up ambient sounds to be the cause of Voxscript lags, while at the same time everything else (direct commands) is behaving perfectly?

[FS++ 708]

 

 

Input Mute On <------------------------------------------hypothetical

 

You could probably achieve that yourself...

 

Go to "advanced panel" options and make sure option "Numlock Mutes reco" is ticked (NumLOck keyboard key enables and disables all MCE speech reco)

 

After that, use the VoxKey tool to create any command (make it long enough so it doen't fire up by accident) and tie it to "NumLock" key.

 

It's a matter of adding that command to the script.

 

Just be aware, when speech reco is suspended, scripted commands won't run.

 

Because all MCE reco would then be suspended, it will be up to you to resume reco by pressing the "NumLock" key.

[KingGhidorah 209]

"Just be aware, when speech reco is suspended, scripted commands won't run"

 

I'm not sure I understand.  You are proposing I use Voxkey to create a Mute command, and put it in the script, but then the script won't run?

 

To clarify, I think you mean that for the duration that the command is active within the script, I won't be able to say "flaps up" or something and have the FO act upon it.  Correct?  That would be ok, because I would only want to selectively mute things for a matter of seconds, during parts of scripts that are known to suffer from hangups (q400 hydraulic pumps during after takeoff do it every time).

 

Having to press the Numlock key, though, to re-enable is not quite ideal, because it requires an artificial intervention similar to occasionally having to say "Pay Attention".  Interestingly, I actually tried putting Pay Attention in one of the laggy voxscripts, and it didn't get the FO back on track like I thought it would, though the spoken command does.

 

All in all, however, now that I realize I need to fool the Wizard into setting a desired mic gain, my performance with MCE is much improved, so I'm not complaining too much, even if I'm not 100% successful in block out all interfering background noise