FO slow to execute his flow

[peterandrew 0]

Hello all,

I'm a new MCE user. I find out that the FO is very slow to execute his flow: apparently one action each 10 seconds or more. So slow sometimes that it seems that I'd  better do the job myself. Is it normal and is there a setting to have the FO acting faster?

regards

 

[FS++ 707]

12 hours ago, peterandrew said:

Hello all,

I'm a new MCE user. I find out that the FO is very slow to execute his flow: apparently one action each 10 seconds or more. So slow sometimes that it seems that I'd  better do the job myself. Is it normal and is there a setting to have the FO acting faster?

regards

 

No, it's not normal.

I suggest you remove any "Pause=whatever" in the flows that is equal or lower than 3 seconds.

Do not assign affinity mask to "mce.exe", as it also runs the entire speech engine inside that process.

You don't want all MCE and speech engine threads fighting over a single CPU core.

It does happen every now and then, but we have yet to understand whether it's MCE itself, the speech engine or the used TTS voice (that also has a speech server app that drives it).

Are you using a TTS voice by any chance? From which vendor.?

Is it happening every time? Please use provided recorded audio (FO Clive) and indicate aircraft and airport used.

 

[peterandrew 0]

Thank you for your answer,

I run P3D4.3.29, MCE, PF3, GSX and Navigraph on a pretty decent computer ( windows 10 64 bit, Intel Core i3-7100 CPU@3.9GHz, 4CPU core, 8GB memory). The aircraft is the pmdg 737NGX for P3D4. The FO voice I used is Lorna. Slow actions from FO occur during the Flows, not during the checklists or the direct actions (Set Heading xxx, Set Altitude xxxx etc..).This happened repetitively during the flight from Houston to New Orleans (Loockeed Martin versions, not 3rd party airport), at ground and airborne  (I experience a long AFTER TAKEOFF FLOW for instance). PF3 works flawless with FO having the radio ( I can't find the way to speak directly to ATC, it's certainly my mistake).

I'll verify the affinity mask affair and try to find those "Pause=whatever" in the flows.

Best regards

[RALF9636 1,889]

I take this chance to chime in and continue what I started here

 

 

which looks to be the same issue.

 

Meanwhile I have made dozens of flights with the FSL A320 and the Majestic Q400.

I am aware that both these aircraft are kind of special because they have a lot going on outside of the sim and MCE uses popup 2D panels for some functions on both aircraft. This peculiarity might or might not contribute to the problem. But I don't have any other complex aircraft to test.

I used Ivona and Cereproc TTS voices as well as some of the prerecorded voices.

 

To make a long story short: The issue persists similarly with both aircraft, regardless of the voice I am using (i.e. also with prerecorded voices). It is effectively happening on every flight, although to different extents, sometimes more noticable than otherwise.

Unfortunately I failed to recognize any pattern. It can happen with any voxscript. It is not that it happens with some special flow all the time. Every flow runs fine some of the time, but then again it is delayed. There is no script that always works fine, neither a script that always is delayed.

It is different all the time. Sometimes the delay between two commands is 1 – 2 seconds (which should be the norm as far as I am aware), sometimes it is maybe 5 or 6 seconds, sometimes even more than 10 seconds. It varies from voxscript to voxscript within a flight. Sometimes everything seems to be normal until one script runs slow. The next is fine again. Or four flows in a row run slow and the next ones work fine again. Of course the issue is more noticable the longer the flow is.

And it is not consistent within a voxscript either. Sometimes the script starts normal and then after a few commands MCE kind of hangs but then again finishes the final few commands normally.

 

To give an example from which I easily recognize the issue:

I use UTLive and I have defined a command "increase traffic density" in voxkey which sends the hotkey to increase the traffic by 5 % in UTL. UTL shows the change of the traffic density in the green text line in the sim.

I included this voxkey command four times in a row in a voxscript (after takeoff flow) to increase the traffic from 40 % to 60 %.

If MCE works normally, the displayed traffic density goes up from 40 to 60 all at one time within a blink of an eye.

If MCE hangs, it goes up in increments of 5 every few seconds, sometimes with ten seconds in between. It also happens that for example it goes up from 40 to 55 at one time and then there is a long pause before it goes up to 60.

To counter any false assumption: This does not only happen with voxkey commands but with all other commands too. I just chose this example because it is so apparent because of the displayed change in traffic density.

 

As I said before the speed of the checklists and the communications with PF3 is not affected in these situations. Also the sim and everything else is running smooth and at a normal speed. Also the speech recognition is not affected (my first assumption that a decrease in the voice recognition rate comes along with this issue didn't prove true - I guess that was more a coincidental problem with my headset calibration).

 

I am using P3D 4.4 on an 8700K at 5.0 Ghz and no affinity settings.

 

 

Eventually, here is the one and only pattern I could recognize, which hopefully might be a hint to what is happening:

 

When MCE hangs, and I say "Attention" the FO replies ("sure" or similar) and immediately moves on to the next command of the voxscript flow, terminating the hanging. That seems to work every time (until the next delay happens).

If I recall correctly "Attention" makes the FO interrupt everything he does and wait for the next command. So I conclude that in the situations when MCE hangs, MCE seems to be busy with some stuff in the background which delays the execution of the voxscript but can be stopped by the "Attention" command.

 

Does that make any sense to you?

Is there any kind of logging I could use to find out what MCE is doing?

 

Edited February 26, 2019 by RALF9636

[FS++ 707]

29 minutes ago, RALF9636 said:

I take this chance to chime in and continue what I started here

 

 

which looks to be the same issue.

 

Meanwhile I have made dozens of flights with the FSL A320 and the Majestic Q400.

I am aware that both these aircraft are kind of special because they have a lot going on outside of the sim and MCE uses popup 2D panels for some functions on both aircraft. This peculiarity might or might not contribute to the problem. But I don't have any other complex aircraft to test.

I used Ivona and Cereproc TTS voices as well as some of the prerecorded voices.

 

To make a long story short: The issue persists similarly with both aircraft, regardless of the voice I am using (i.e. also with prerecorded voices). It is effectively happening on every flight, although to different extents, sometimes more noticable than otherwise.

Unfortunately I failed to recognize any pattern. It can happen with any voxscript. It is not that it happens with some special flow all the time. Every flow runs fine some of the time, but then again it is delayed. There is no script that always works fine, neither a script that always is delayed.

It is different all the time. Sometimes the delay between two commands is 1 – 2 seconds (which should be the norm as far as I am aware), sometimes it is maybe 5 or 6 seconds, sometimes even more than 10 seconds. It varies from voxscript to voxscript within a flight. Sometimes everything seems to be normal until one script runs slow. The next is fine again. Or four flows in a row run slow and the next ones work fine again. Of course the issue is more noticable the longer the flow is.

And it is not consistent within a voxscript either. Sometimes the script starts normal and then after a few commands MCE kind of hangs but then again finishes the final few commands normally.

 

To give an example from which I easily recognize the issue:

I use UTLive and I have defined a command "increase traffic density" in voxkey which sends the hotkey to increase the traffic by 5 % in UTL. UTL shows the change of the traffic density in the green text line in the sim.

I included this voxkey command four times in a row in a voxscript (after takeoff flow) to increase the traffic from 40 % to 60 %.

If MCE works normally, the displayed traffic density goes up from 40 to 60 all at one time within a blink of an eye.

If MCE hangs, it goes up in increments of 5 every few seconds, sometimes with ten seconds in between. It also happens that for example it goes up from 40 to 55 at one time and then there is a long pause before it goes up to 60.

To counter any false assumption: This does not only happen with voxkey commands but with all other commands too. I just chose this example because it is so apparent because of the displayed change in traffic density.

 

As I said before the speed of the checklists and the communications with PF3 is not affected in these situations. Also the sim and everything else is running smooth and at a normal speed. Also the speech recognition is not affected (my first assumption that a decrease in the voice recognition rate comes along with this issue didn't prove true - I guess that was more a coincidental problem with my headset calibration).

 

I am using P3D 4.4 on an 8700K at 5.0 Ghz and no affinity settings.

 

 

Eventually, here is the one and only pattern I could recognize, which hopefully might be a hint to what is happening:

 

When MCE hangs, and I say "Attention" the FO replies ("sure" or similar) and immediately moves on to the next command of the voxscript flow, terminating the hanging. That seems to work every time (until the next delay happens).

If I recall correctly "Attention" makes the FO interrupt everything he does and wait for the next command. So I conclude that in the situations when MCE hangs, MCE seems to be busy with some stuff in the background which delays the execution of the voxscript but can be stopped by the "Attention" command.

 

Does that make any sense to you?

Is there any kind of logging I could use to find out what MCE is doing?

 

Thanks for the extensive report and the clue.

Will be looked at as soon as possible.

[peterandrew 0]

On 2/26/2019 at 10:04 PM, RALF9636 said:

If I recall correctly "Attention" makes the FO interrupt everything he does and wait for the next command. So I conclude that in the situations when MCE hangs, MCE seems to be busy with some stuff in the background which delays the execution of the voxscript but can be stopped by the "Attention" command.

Just to mention that Ralph observation is right.

I test the "ELECTRICAL PROCEDURE WITH APU". The flow hangs; each time I call "attention" the FO execute the next step. Without doing that I've to wait up to 30s to have the next step executed.

[FS++ 707]

OK, please have a go at this experimental package

Thank you.

[peterandrew 0]

Many Thank I'll try this package

[peterandrew 0]

First test of the new package:

"Electrical Power up with APU" : 3 minutes

"Prepare AIrcraft" : 13 minutes

So not much differences with the previous package and always about 10 to 20 seconds between each actions.

 

All the best

[FS++ 707]

3 hours ago, peterandrew said:

First test of the new package:

"Electrical Power up with APU" : 3 minutes

"Prepare AIrcraft" : 13 minutes

So not much differences with the previous package and always about 10 to 20 seconds between each actions.

 

All the best

Have to wait for other users feedback.

Are you using a USB headset or a conventional one?

If it's conventional with 3 mm jacks, what sound device is it connected to? Motherboard sound chip (Realtek or other), or custom sound card?

[RALF9636 1,889]

Unfortunately no improvement with 2.7.90 for me either.

I have the MCE sound output assigned to my monitor, so that the MCE sound is played through the headset which is connected to my monitor (the latter being connected via HDMI to my 1080TI). The microphone is connected to the default Realtek device. All by cable and 3mm jacks.

Edited March 3, 2019 by RALF9636

[peterandrew 0]

 

• 
  I use a conventionnal headset with 3 mm jacks. The sound device is the Motherboard sound chip (Realtek)

[FS++ 707]

 

I suggest this to anyone who has a built-in Realtek audio device.

The Windows own x64 digitally signed drivers appear to perform better on x64 platforms.

Go to Windows Control Panel, add remove programs.

Locate "Realtek Hi-definition audio" and uninstall it.

Restart Windows and let it detect sound device and assign it Windows own drivers.

 

 

[peterandrew 0]

I'll try to change the realtek sound drivers to windows sound drivers. Anyway, with realtek audio divices, the voice recognition works perfectly as indicated by the red writing in the upper left corner of the window.

[RALF9636 1,889]

On 3/4/2019 at 11:50 AM, FS++ said:

 

I suggest this to anyone who has a built-in Realtek audio device.

The Windows own x64 digitally signed drivers appear to perform better on x64 platforms.

Go to Windows Control Panel, add remove programs.

Locate "Realtek Hi-definition audio" and uninstall it.

Restart Windows and let it detect sound device and assign it Windows own drivers.

 

 

 After I uninstalled the Realtek HD Audio indeed the delays of the script execution have been minimised during my last two flights. There still have been some variances in the speed of the script execution but so minor I wouldn't probably have noticed them at all if I hadn't been looking for them.

Too early for a final verdict though after only two flights, but it looks promising.