A Practical Speech Synthesis System

The Festival Speech Synthesis Systems was developed at the Centre for Speech Technology Reseach at the University of Edinburgh in the late 90's. It offers a free, portable, language independent, run-time speech synthesis engine for verious platforms under various APIs. This book is not about the Festival system itself, Festival is just the engine that we will use in the process of building voices, both as a run-time engine for the voices we build and as a tool in the building process itself. This chapter gives a background on the philosophy of the system, its basic use, and some lower level details on its internals that will make the understanding of the whole synthesis task easier.

The Festival Speech Synthesis System was designed to target three particular classes of speech synthesis user.

1. Speech synthesis researchers: where they may use Festival as a vehicle for developmeent and testing of new research in synthesis technology.

2. Speech application developers: where synthesis is not the primary interest, but Festival will be a substantial sub-component which may require significant integration and hence the system must be open and easily configurable.

3. End user: where the system simple takes text and generates speech, requiring no or very little configuration from the user.

In the design of Festival it was important that all three classes of user were served as there needs to be a clear route from research work to practial usable systems as this not only encourages research to be focussed but also, as has been shown by the large uptake of the system, ensures there is a large user community interested in seeing improvements to the system.

The Festival Speech Synthesis System was built based on the experience of previous synthesis engines. Design of a key architecture is important as what may seem general to begin with can quickly become a limiting factor, as new and more ambitious techniques are attempted within it. The basic architecture of Festival benefited mainly from previous synthesis engines developed at Edinburgh University, specifically Osprey [taylor91]. ATR's CHATR system, [black94] was also a major influence on Festival, CHATR's original core architecture was also developed by the same authors as Festival. In designing Festival, the intention was to avoid the previous limitations in the utterance representation and module specification, specifically in avoiding constraints on the types of modules and dependencies between them. However even with this intent, Festival went through a number of core changes before it settled.

The Festival system consists of a set of C++ objects and core methods suitable for doing synthesis tasks. These objects include synthesis specific objects like, waveforms, tracks and utterances as well as more general objects like feature sets, n-grams, and decision trees.

In order to give parameters and specify flow of control Festival offers a scripting language based on the Scheme programming language [Scheme96]. Having a scripting language is one of the key factors that makes Festival a useful system. Most of the techniques in this book for building new voices within Festival can be done without any changes to the core C++ objects. This makes development of new voices not only more accessible to a larger population or users, as C++ knowledge nor a C++ compiler is necessary, it also makes the distribution of voices built by these techniques easy as users do not require any recompilation to use newly created voices.

Scheme offers a very simple syntax but powerful language for specifying parameters and simple functions. Scheme was chosen as its implementation is small and would not increase the size of the Festival system unnecessarily. Also, using an embedded Scheme component does not increase the requirements for installation as would the use of say Java, Perl or Python as the scripting language. Scheme frightens some people as Lisp based languages have an unfair reputation for being slow. Festival's use of Scheme is (in general) limited to simple functions and very little time is spent in the Scheme interpreter itself. Automatic garbage collection also has a reputation for slowing systems down. In Festival, garbage collection happens after each utterance is synthesized and again takes up only a small amount of time but allows the programmer nor to have to worry about explicitly freeing memory.

For the most part the third type of user, defined above, will never need to change any part of the systems (though they usually find something they want to change, like adding new entries to the lexicon). The second level of user typically does most of their customizing in Scheme, though this is usually just modifying existing pieces of Scheme in the way that people may add simple lines of Lisp to their .emacs file. It is primarily only the synthesis research community that has to deal with the C++ end of the system, though C/C++ interfaces to the systems as a library are also provided (see the Chapter called Festival Details for more discussions on APIs).

This chapter covers the basic use of the system and is followed by more details of the internal structures, particularly the utterance sturcture, accessing methods and modules. These later sections are probably more detail than one needs for building standard voices described in the book, but the is information is necessary when more ambituous voice building tasks are attempted.