How text-to-speech is configured

As described below, the plug-in class to be used for converting text to speech for any individual text-to-speech string is found using TTSService configuration entries and TTSDefinitions. However for VoiceXML applications you should specify the locale by including the <vxml> xml:lang attribute in your VoiceXML documents, to ensure that the correct built-in resources are used.

How is the TTSService configuration entry used?

You should have a TTSService configuration entry for each plug-in on each operating system platform you use in your Blueworx Voice Response Java and VoiceXML Environment plex. This is simple if you have a homogeneous system, for example, all your voice response nodes run AIX. It is simpler still if you have only one text-to-speech technology.

If you do have voice response nodes with different operating systems, the TTSService entries for each one is distinguished by the TTSService=name. The TTSType=name keyword identifies the technology, which should be the same on both (or all) TTSService entries.

Each voice response node has a NodeName configuration entry, in which the relevant TTSService entries are identified.

MRCP can be configured so that in the event of a configured MRCP resource becoming unavailable, a secondary back-up server can take over so that MRCP activity can continue. The speech synthesis session is restored on the backup server to the same state as the primary server prior to the failure. Any synthesis parameters, or session variables being used are also reinstated, so that the recovered session functions in the same way as the working primary server. The URI of the back-up server is specified by the second InitSessionString keyword in a TTSService entry in configuration file default.cff.

For more detailed information about the TTSService configuration entry, including examples, see TTSService configuration entry.

What is a TTSDefinition?

A TTSDefinition contains two items of information: TTSType and locale identifier. TTSType is a platform-independent name for the text-to-speech technology. The locale identifier identifies the languages for which this technology is to be used. The locale identifier can be an asterisk (*), indicating “all locales”. For more information about locale identifiers, see How languages are identified in VoiceXML and Java.

Hint: It is often convenient to configure a plug-in for a language instead of the full locale. For example, if you have a German TTS engine and configure it for the "de" locale, applications running in de_DE, de_AT, and de_CH can all use this TTS service for text-to-speech. If you configure it for "de_DE", applications running in de_AT and de_CH will not be able to access the resource.

If you are running VoiceXML applications that use text-to-speech, you must include a TTSDefinition for the language-only part of your locale as well as a TTSDefinition for the full locale. For example, to run a VoiceXML application in the en_US locale, you must include the following TTSDefinition entries:

TTSDefinition=en,ttsType
TTSDefinition=en_US,ttsType

where ttsType is the name of your TTSType.

Applications running in an unsupported locale will use the language-only TTSDefinition for default behaviour such as error messages. For example, if you are running a VoiceXML application in New Zealand, with a locale of en_NZ, your TTSDefinitions will be as follows:

TTSDefinition=en,ttsType
TTSDefinition=en_NZ,ttsType

In the above example, if your application encounters an error which causes it to play the default error message "Sorry, must exit due to processing error", this message will play in the 'en' locale, which is American English. The dialect of the 'en' locale may not be correct for your application, in which case, you should provide your own default behaviour.

Where should you put the TTSDefinitions?

There are three places where you can put TTSDefinitions. The simplest is to put them in the NodeName configuration entry. These definitions apply to all applications run in the node.

If you need to specify different technologies for different applications, you can override the TTSDefinitions in the NodeName entry, by putting TTSDefinitions in the AppName configuration entry. Read Specifying TTSDefinitions for an application if you need to do this.

The bottom line is: put the definitions in the NodeName entry unless your applications need to use different technologies.