Understanding the speech application environment

To estimate the application load on the system, you need to know the following:

• The number of telephony channels required to handle the number of calls you expect for applications using WebSphere Voice Server technology. You must consider how long on average each caller is expected to wait before being answered.
• The call frequency and distribution – whether the number of calls likely to be made is the same throughout the day, or if the call pattern is likely to vary significantly, with peaks and troughs in demand.

  Your WebSphere Voice Server system should be able to handle the maximum demand for speech resources. That is, the resources needed at the peak calling hour rather than a day's average number of hourly calls. The primary speech resource is the ASR or TTS engine. The demand for engines is influenced by both the frequency of calls and how they are distributed. If all the incoming calls use the same application and start at the same time, each call will need an engine at the same time so the demand will be high. If, on the other hand, calls are distributed normally, the number of engines needed simultaneously can be considerably smaller.

  For your applications, you must determine the acceptable performance or desirability of an engine being available for a call without a significant delay. Delays can cause performance degradation, such as not recognizing speech input or stuttering output. If a degradation of performance is acceptable during peak utilization, fewer engines will be required.

• The time that engines are allocated, or assigned, as a proportion of a call. This is known as the allocation duty cycle. ASR and TTS engines are dynamically allocated on an as needed basis, which means they are allocated to perform a single operation (recognition or synthesis) and then immediately freed.
• The time that engines are active (recognizing speech or synthesizing text to be played) as a proportion of a call. This is known as the active duty cycle. This can vary considerably, depending on the design of your voice applications and their complexity. These factors determine the number of concurrent ASR and TTS sessions that are required.

  The number of concurrent ASR and TTS sessions, in turn, determines the number of processors required and how powerful they must be. Similarly, these two variables – number and speed of the processors – dictate the number and size of the machines needed for your WebSphere Voice Server installation.

  For example, a non-barge-in application using long prompts of synthesized text together with a simple grammar is likely to be actively engaged in recognition for only a short proportion of the length of a call. It will have a short active duty cycle for ASR but a long active duty cycle for speech synthesis.

  A barge-in application using shorter prompts of synthesized text together with a complex grammar is likely to spend more time actively engaged in recognition. In this case, the active duty cycle for ASR will be longer and the active duty cycles for speech synthesis shorter. If a system is underspecified, an engine might not be available at the start of a call.

The following figures show a comparison of ASR and TTS engine allocation. In this figure, a barge-in application is being used.

Figure 1. ASR and TTS engine allocation comparison (speech recognition with barge-in)

In this figure, a non-barge-in application is being used.

Figure 2. ASR and TTS engine allocation comparison (speech recognition without barge-in)