locked
Average recording latency is too high RRS feed

  • Question

  • Does anyone know what this means or what would cause this?


     

    Event Type:    Error
    Event Source:    Office Communications Server 2007 Speech Server
    Event Category:    Telephony Application Host
    Event ID:    29014
    Date:        5/9/2008
    Time:        12:00:40 AM
    User:        N/A
    Computer:    *****
    Description:
    An http request for URL '*****' was rejected for the following reason: The session cannot be created because the average recording latency is too high..
     
    Further trace information for support personnel follows:
     
    Microsoft.SpeechServer.SpeechEngineServices.ServerTooBusyException: The session cannot be created because the average recording latency is too high.

    Server stack trace:
      at Microsoft.SpeechServer.SessionManager.CheckLoad(SesContext context, Boolean inbound, Boolean applyRateThrottling)
      at Microsoft.SpeechServer.SessionManager.CreateSession(SesContext context, IBrokerSessionListener listener, Boolean inbound, Boolean applyRateThrottling, IRemotingEventBatchReceiver sesProxyReceiver, Guid sesProxyReceiverId, IRemotingEventBatchReceiver& sesMainReceiver, Guid& sesMainReceiverId, Boolean proxyInDebugger)
      at Microsoft.SpeechServer.Broker.CreateSession(SesContext sesContext, IBrokerSessionListener listener, Boolean inbound, Boolean applyRateThrottling, IList`1& supportedVoices, IRemotingEventBatchReceiver sesProxyReceiver, Guid sesProxyReceiverId, IRemotingEventBatchReceiver& sesMainReceiver, Guid& sesMainReceiverId, Boolean proxyInDebugger)
      at Microsoft.SpeechServer.AuthenticatedBrokerSessionManager.CreateSession(SesContext sesContext, IBrokerSessionListener listener, Boolean inbound, Boolean applyRateThrottling, IList`1& supportedVoices, IRemotingEventBatchReceiver sesProxyReceiver, Guid sesProxyReceiverId, IRemotingEventBatchReceiver& sesMainReceiver, Guid& sesMainReceiverId, Boolean proxyInDebugger)
      at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
      at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
      at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

    Exception rethrown at [0]:
      at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
      at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
      at Microsoft.SpeechTransport.CreateSessionDelegate.EndInvoke(IList`1& supportedVoices, IRemotingEventBatchReceiver& sesMainReceiver, Guid& sesMainReceiverId, IAsyncResult result)
      at Microsoft.SpeechTransport.SessionInfo.CreateSessionComplete(IAsyncResult ar)

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Thursday, May 15, 2008 3:36 PM

All replies

  • Speech Server monitors various latencies as a measure of how loaded the system is.  If any latency is too high (looking at a recent historical average), calls will be rejected until the average latency drops.  That is what is happening here.  It ensures that Speech Server doesn't get overloaded by too many simultaneous calls.

    Monday, May 19, 2008 10:38 AM
  • Okay. 

     

    I think what happened here is that we changed the AudioEncoding property on a RecordAudioActivity from Pcm (default) to Ulaw.  That's the only related thing that we have changed before seeing this. 

     

    Why would that cause a high recording latency?  The RTP that is coming in is µ-law so it seems like saving µ-law as opposed to PCM would be faster.

    Monday, May 19, 2008 1:51 PM
  • What's the CPU / call load at the time?  I would only expect to see this warning if the system is under heavy load.  Have you observed any performance difference following the switch to µ-law?  You would certainly expect that saving in the same format as the incoming audio would be quickest; I'm not familiar enough with this area to comment.

     

    Monday, May 19, 2008 2:07 PM
  • I don't know what the CPU was at the time, but our call load hasn't changed much recently.  And the workflow that the RecordAudioActivity is in gets called about 5 times a day at the most.  So we wouldn't really notice any performance difference overall anyway.

     

    This is the only change that could have affected this.

    Monday, May 19, 2008 7:07 PM