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.

  

 

I follow your recommendation and it looks that you pointed out the true issue. A first test gives 1.2 mn for Electrical power up with APU instead of 3 mn; for the "prepare aircraft" procedure it takes now 5 mn instead of 13 mn. I'll continue the testing

Many thanks

I achieve a flight  (KIAD-KALB) from C&D to C&D .With le last package and the win10 own x64 sound drivers I now have a normal behaviour of the FO.

Thanks again for your help

10 hours ago, peterandrew said:

I achieve a flight  (KIAD-KALB) from C&D to C&D .With le last package and the win10 own x64 sound drivers I now have a normal behaviour of the FO.

Thanks again for your help

You're welcome.

Appreciate the feedback, as I rarely experience those delays on a USB headset (which has its own built-in audio device driven by a generic Windows USB audio driver.

Always knew that Realtek drivers aren't up to scratch with audio in (the part most people use the least).

I guess since Microsoft is the author of the speech engine, they ensure their drivers meet all requirements and not just output sound, take some in and remain stable.,

Thank you to Ralf as well.

Update after 20+ flights after uninstalling the Realtek HD Audio:

The issue is not completely gone for me. The slow execution of the flows still happens from time to time. But it is a lot less frequent and less pronounced than before. It has become so infrequent that I don't consider a problem any more for me. I see it as a welcome additional random element instead ;-).

 

Furthermore I found another way to cure the issue immediately (apart from saying "attention"): Pressing the mute key (NumLock) to suspend any voice recognition.

And when I press NumLock immediately after starting a voxscript the issue seems to never occur at all.

 

A strange finding by the way: When Numlock is pressed (so all voice recognition is suspended) MCE still picks up an "attention" out of nothing from time to time.

 

The hanging of MCE still occurs to me occasionally.

But I think I found a pattern now, finally:

The problem with MCE getting slow seems to occur most of the times when I call for a voxscript while or immediately after the FO is talking to PF3. If I wait for several seconds after he has finished his transmission, all is fine.

So it seems there is some kind of conflict between the tasks of communicating with PF3 and executing the voxscript, which makes MCE hang.

Can you try and see if you can replicate this issue?

If the conflict itself can't be solved easily, a fix could be that the voxscript is just blocked while the FO is busy with PF3 - just like it is when he already executes another voxscript ("I can handle only one thing at a time").

 

 

2 hours ago, RALF9636 said:

The hanging of MCE still occurs to me occasionally.

But I think I found a pattern now, finally:

The problem with MCE getting slow seems to occur most of the times when I call for a voxscript while or immediately after the FO is talking to PF3. If I wait for several seconds after he has finished his transmission, all is fine.

So it seems there is some kind of conflict between the tasks of communicating with PF3 and executing the voxscript, which makes MCE hang.

Can you try and see if you can replicate this issue?

If the conflict itself can't be solved easily, a fix could be that the voxscript is just blocked while the FO is busy with PF3 - just like it is when he already executes another voxscript ("I can handle only one thing at a time").

 

 

This one is actually by design.

Think of Voxscript as a speech simulator.

Each command present in a script is submitted to the speech engine as if you spoke it, and MCE has to wait until speech engine has recognized it and act accordingly. This explains why sometimes the speech engine doesn't return result immediately (explains some of the random latency)

Now, to make the ATC feature efficient, you can't have  tens of thousands of commands for Fo interaction all enabled in addition to all ATC commands.

When you hold PTT switch down, all commands for Fo interaction are disabled and those for ATC are enabled.

In doing so, it means that if Fo is currently executing a flow and you happen to have PTT down, speech engine would not detect cockpit commands as they are disabled.You wouuld get "Command doesn't seem to exist" in red font.

Therefore, by design, the background thread executing the flow is deliberately put on hold while PTT is seen down, and will resume a few seconds after it's released.

For performance reasons, it doesn't check whether PTT is released furiously, but rather gives you plenty of time to transmit before doing so, hence the perception of long delay.

There is certainly room for improvement there to shorten it. Will be done in next update

 

 

8 hours ago, FS++ said:

 

Now, to make the ATC feature efficient, you can't have  tens of thousands of commands for Fo interaction all enabled in addition to all ATC commands.

When you hold PTT switch down, all commands for Fo interaction are disabled and those for ATC are enabled.

In doing so, it means that if Fo is currently executing a flow and you happen to have PTT down, speech engine would not detect cockpit commands as they are disabled.You wouuld get "Command doesn't seem to exist" in red font.

Therefore, by design, the background thread executing the flow is deliberately put on hold while PTT is seen down, and will resume a few seconds after it's released.

For performance reasons, it doesn't check whether PTT is released furiously, but rather gives you plenty of time to transmit before doing so, hence the perception of long delay.

 

 

So this is also valid in the "you have ATC"-mode, where I do not press the PTT but the FO simulates it being pressed? Because that is the situation I was talking about.

If so, I don't think it is necessary to disable commands for FO interaction in that situation at all. The speech engine is not needed for ATC commands because the FO handles ATC, reading from the PF3-file.

 

3 hours ago, RALF9636 said:

 

 

So this is also valid in the "you have ATC"-mode, where I do not press the PTT but the FO simulates it being pressed? Because that is the situation I was talking about.

If so, I don't think it is necessary to disable commands for FO interaction in that situation at all. The speech engine is not needed for ATC commands because the FO handles ATC, reading from the PF3-file.

 

No, it's not disabled when FO is handling ATC.

Only when PTT is physically down, which isn't required when FO is transmitting..

So this cannot be an explanation for what I am experiencing. I am not pressing PTT in these situations.