Go to the first, previous, next, last section, table of contents.


5 Installation

This section describes how to install Festival from source in a new location and customize that installation.

5.1 Requirements

In order to compile Festival you first need the following source packages

festival-1.2.x.tar.gz
Festival Speech Synthesis System source
speech_tools-1.0.x.tar.gz
The Edinburgh Speech Tools Library
festlex_NAME.tar.gz
The lexicon distribution, where possible, includes the lexicon input file as well as the compiled form, for your convenience. The lexicons have varying distribution policies. In some cases only a pointer to an ftp'able file plus a program to convert that file to the Festival format is included.
festvox_NAME.tar.gz
You'll need a speech database. A number are available (with varying distribution policies). Each voice may have other dependencies such as requiring particular lexicons
festdoc_1.2.x.tar.gz
Full postscript, info and html documentation for Festival and the speech tools. The source of the documentation is available in the standard distributions but for your conveniences it has been pre-generated.

In addition to Festival specific sources you will also need

A UNIX machine
Currently we have compiled and tested the system under Solaris (2.4 and 2.5), SunOS (4.1.3), FreeBSD 2.1 (and 2.2), Linux, OSF1 3.2 (DEC Alphas). and it should work under SGI (Irix), HPs (HPUX). But any standard UNIX machine should be acceptable. We have now successfully ported this version to Windows NT nad Windows 95 (using the Cygnus GNU win32 environment). This is still a young port but seems to work.
A C++ compiler
Note that C++ is not very portable even between different versions of the compiler from the same vendor. Although we've tried very hard to make the system portable, we know it is very unlikely to compile without change except with compilers that have already been tested. The currently tested systems are Note if GCC works on one version of Unix it usually works on others. We no longer require GNU's `libg++' to provide String support but do still require `iostream' support from the library. In GCC 2.6.3 the iostream support is still in `libg++' but this was separated in later versions into `libstdc++'. We recommend GCC 2.7.2 which we use as our standard compiler. It is (mostly) standard across platforms and compiles faster and produces better code than any of the other compilers we've used. Note when using GCC you also need the C++ library that goes with it, even though we don't use `libg++' we do require `stdc++', (when using GCC 2.7.2). We have compiled both the speech tools and Festival under Windows NT 4.0 and Windows 95 using the GNU tools available from Cygnus.
`ftp://ftp.cygnus.com/pub/gnu-win32/'.
GNU make
Due to there being too many different make programs out there we've settled for one that works on all systems we use. You'll need this too.
GNU readline library
The GNU readline library is used for command input offering command line editing, history, and function, variable and filename completion. Festival may be compiled to run without it but then it looses much of its fun.
Audio hardware
You can use Festival without audio output hardware but it doesn't sound very good (though admittedly you can hear less problems with it). A number of audio systems are supported (directly inherited from the audio support in the Edinburgh Speech Tools Library): NCD's NAS (formerly called netaudio) a network transparent audio system (which can be found at `ftp://ftp.x.org/contrib/audio/nas/'); `/dev/audio' (at 8k ulaw and 16bit linear), found on Suns, Linux machines and FreeBSD; and a method allowing arbitrary UNIX commands. See section 21 Audio output.

In addition to the above, in order to process the documentation you will need `TeX', `dvips' (or similar), GNU's `makeinfo' (part of the texinfo package) and `texi2html' which is available from `http://wwwcn.cern.ch/dci/texi2html/'.

However the document files are also available pre-processed into, postscript, DVI, info and html as part of the distribution in `festdoc-1.2.X.tar.gz'.

Most of the related software not part of the Festival distribution has been made available in

ftp://ftp.cstr.ed.ac.uk/pub/festival/extras/

Ensure you have a fully installed and working version of your C++ compiler. Most of the problems people have had in installing Festival have been due to incomplete or bad compiler installation. It might be worth checking if the following program works if you don't know if anyone has used your C++ installation before.

#include <iostream.h>
int main (int argc, char **argv)
{
   cout << "Hello world\n";
}

Unpack all the sources files in a new directory. The directory will then contain two subdirectories

speech_tools/
festival/

5.2 Configuration

First ensure you have a compiled version of the Edinburgh Speech Tools Library. See `speech_tools/INSTALL' for instructions.

Before compilation of Festival it is necessary to configure your implementation to be aware of the environment it is being compiled in. Specifically it must know the names of various local programs, such as your compiler; directories were local libraries are held, and choices for various options about sub-systems it is to use.

All compilation information is set in a local per installation file called `config/config_make_file'. You should copy the example one, mark it writable and edit it according to your local set up.

cd config/
cp config_make_rules-dist config_make_rules
chmod +w config_make_rules

`config/config_make_rules' is included by all `Makefiles' in the system and therefore should be the only place machine specific information need be changed. Note that all `Makefiles' define the variable TOP to allow appropriate relative addressing of directories within the `Makefiles' and their included files.

First select the compiler you are using and general compiler flags for optimisation, warning and debug level. Then select any of the extra options. If you compiled your speech tools with NAS support you should also include that here. Readline is thoroughly recommended, its makes the command interpreter much easier to use. The TCL support was primarily added for using Festival with OGI's CSLU toolkit but may be useful for other applications too.

Check the compiler settings are correct for your installation.

Comments in `config_make_rules' aid the various choices. But some points deserve specific comment. At run-time, Festival requires read access to its library directory. The library directory should be set at compile time. It may be changed at run time with the command line option `--libdir', but it makes calls to the system much easier if you set it before compilation. Set the `Makefile' variable FTLIBDIR. By default, the current directory will be set, so that the `festival' executable will look for the library in the position it has been unpacked. But, note that because Unix (conspiring with NFS and automounters) cannot guarantee that `pwd' will return valid a network-wide name for a directory. You may wish to edit this yourself.

If you are going to share the library directory between different architectures it is necessary to ensure the UNIX environment variable OSTYPE is set at compile time. This may be set in `config_make_rules' explicitly or may be set already in your Unix environment. Typical values are SunOS5, Linux and FreeBSD. Note that if you intend to use the system under SunOS for sparcs and for intel machines you'll need to have an OSTYPE value that distinguishes between them. Only a few executables are architecture dependent in Festival. All of which are stored in `lib/etc/$OSTYPE/'. Lexicons, voice databases etc are architecture independent.

On Sun's Solaris (and possibly other SYSV based Unixes) you may need to explicitly include socket libraries. Set SOCKET_LIBS accordingly.

If your installation includes the file src/modules/diphone/di_psolaTM.cc, then uncomment PSOLA_DEFS. This file includes code which may be covered by a patent owned by France Telecom (CNET). To avoid any legal problems this file is not distributed with the basic system.

Identify the directory where the compiled speech tools library and include files are. The default may be correct if you unpacked the speech tools and Festival together.

The readline library is thoroughly recommended, but is optional. Without readline, history, command-line editing and completion will be missing. Readline is available from various ftp sites throughout the world including `ftp://prep.ai.mit.edu/gnu/readline-2.1.tar.gz'. It may already be installed on your system. (It is also provided with bash, gdb etc.) Note that the file `src/arch/siod-3.0/siodline.c' which provides the interface to the readline library assumes that the readline `.h' files are in a subdirectory called `readline/' in the specified include directory. This may not be the case in a default installation of readline. If so copy all include files in the `.../readline-2.1/' directory into a new subdirectory called `.../readline-2.1/readline/'.

One some machines `readline' incorrectly uses the macro sigmask as a function and hence is left unresolved at link time. In this case uncomment the line in `config/config_make_rules' the defines sigmask_fix.

Note that some versions of readline (e.g. the one from `gdb-4.16')) will give warnings about implicit declarations of functions but will compile and link correctly. I have some indication that some versions of readline cause compilation of siodline.c to fail to compile due to a missing definition of CPPFunction, in that case either take a newer or older version of readline (i.e. `readline-2.0' or from `gdb-4.16').

If your speech tools library is compiled with NCD's NAS support then identify where the library exists on your system

Once `config/config_make_rules' is set up you can build the system. Note that the speech tools library needs to be compiled first.

First create the include dependencies with

gnumake depend

This will produce what looks like errors about missing files. This is normal. This makes the file `make.depend' in each directory stating the dependencies of include files. Although it complains that it can't find `make.depend', it will immediately make the file. If however it complains that it is unable to find include files that are part of the speech tools library, then ESTOOLSDIR is probably wrong.

Now you can build the `festival' binary

gnumake

The `festival' binary should be built in `src/main/festival'.

Note that the single most common reason for problems in compilation and linking found amongst the beta testers was a bad installation of GNU C++. If you get many strange errors in G++ library header files or link errors it is worth checking that your system has the compiler, header files and runtime libraries properly installed. This may be checked by compiling a simple program under C++ and also finding out if anyone at your site has ever used the installation. Most of these installation problems are caused by upgrading to a newer version of libg++ without removing the older version so a mixed version of the `.h' files exist.

Every effort has been made for Festival to compile with no warnings but depending on your system you may get a few. If these are for system calls (like signal) they are probably innocuous. If you get many then there is probably a problem.

However under SunOS the system include files do not declare a number of system provided functions. This a bug in Sun's include files. This will causes warnings like "implicit definition of fprintf". These are harmless.

Under Sun's Solaris 2.4 you need to add `/usr/ucbinclude' to the INCLUDES variable in `festival/config/config_make_rules'.

Under Sun's CC compiler a number of warnings are given about not being able to find source, particularly for operator << and some == operators. It is unclear why this should be a warning as the code exists in other files deliberately for modularity purposes and should not be visible in these files anyway. These warnings are harmless.

Under Linux a warning at link time about reducing the size of some symbols often is produced. This is harmless.

Under Windows NT and Windows 95 the version of gcc includes from Cygnus in hte GNU Wwin32 suite is a newer version and although called 2.7.2-970404 it is in fact closer 2.8.0. A number of warnings are produced which should not really be warnings and should have a compiler flag to switch them off (they do in fact buts its undocumented). The warnings involve "non-virtual destructor functions". These warnings are harmless.

The speech tools and festival compile under Windows95 or Windows NT with Visual C++ v5.0 using the Microsoft `nmake' make program. We've only done this with the Professonal edition, but have no reason to believe that it relies on anything not in the standard edition.

In accordance to VC++ conventions, object files are created with extension .obj, executables with extension .exe and librararies with extension .lib. This may mean that both unix and Win32 versions can be built in the same directory tree, but I wouldn't rely on it.

To do this you require nmake Makefiles for the system. These can be generated from the gnumake Makefiles, using the command

gnumake VCMakefile

in the speech_tools and festival directories. I have only done this under unix, it's possible it would work under the cygnus gnuwin32 system.

If `make.depend' files exist (i.e. if you have done `gnumake depend' in unix) equivalent `vc_make.depend' files will be created, if not the VCMakefiles will not contain dependency information for the `.cc' files. The result will be that you can compile the system once, but changes will not cause the correct things to be rebuilt.

In order to compile from the DOS command line using Visual C++ you need to have a collection of environment variables set. In Windows NT there is an instalation option for Visual C++ which sets these globally. Under Windows95 or if you don't ask for them to be set globally under NT you need to run

vcvars32.bat

See the VC++ documentation for more details.

Once you have the siurce trees with VCMakefiles somewhere visible from Windows, you need to copy `peech_tools\config\vc_config_make_rules-dist' to `speech_tools\config\vc_config_make_rules' and edit it to suit your local situation. Then do the same with `festival\config\vc_config_make_rules-dist'.

The thing most likely to need changing is the definition of FTLIBDIRC in `festival\config\vc_config_make_rules' which needs to point to where you have put festival.

Now you can compile. cd to the speech_tools directory and do

nmake /nologo /fVCMakefile 

and the library, the programs in main and the test programs should be compiled.

The tests can't be run automaticly under Windows. A simple test to check that things are probably OK is:

main\na_play testsuite\data\ch_wave.wav

which reads and plays a waveform.

Next go into the festival directory and do

nmake /nologo /fVCMakefile 

to build festival. When it's finished, and assuming you have the voices and lexicons unpacked in the right place, festival should run just as under unix.

We should remind you that the NT/95 ports are still young and there may yet be problems that we've not found yet. We only recommend the use the speech tools and Festival under Windows if you have significant experience in C++ under those platforms.

5.3 Site initialization

Once compiled Festival may be further customized for particular sites. At start up time Festival loads the file `init.scm' from its library directory. This file further loads other necessary files such as phoneset descriptions, duration parameters, intonation parameters, definitions of voices etc. It will also load the files `sitevars.scm' and `siteinit.scm' if they exist. `sitevars.scm' is loaded after the basic Scheme library functions are loaded but before any of the festival related functions are loaded. This file is intended to set various path names before various subsystems are loaded. Typically variables such as lexdir (the directory where the lexicons are held), and voices_dir (pointing to voice directories) should be reset here if necessary.

The default installation will try to find its lexicons and voices automatically based on the value of load-path (this is derived from FTLIBDIR at compilation time or by using the --libdir at run-time). If the voices and lexicons have been unpacked into subdirectories of the library directory (the default) then no site specific initialization of the above pathnames will be necessary.

The second site specific file is `siteinit.scm'. Typical examples of local initialization are as follows. The default audio output method is NCD's NAS system if that is supported as that's what we use normally in CSTR. If its not supported any hardware specific mode is the default (e.g. sun16audio, freebas16audio, linux16audio or mplayeraudio). But that default is just a setting in `init.scm'. If for example in your environment you may wish the default audio output method to be through `/dev/audio' you should add the following line to your `siteinit.scm' file

(Parameter.set 'Audio_Method 'sunaudio)

Note the use of Parameter.set rather than Parameter.def the second function will not reset the value if it is already set. Remember that you may use the audio methods sun16audio. linux16audio or freebsd16audio only if selected in `speech_tools/config/config_make_rules'.

If you are installing on a machine whose audio is not directly supported by the speech tools library, we must exec a Unix command that can play the file. The example is for an imaginary machine that can play audio files through a program called `adplay' with arguments for sample rate and file type. When playing waveforms, Festival, by default, outputs an unheadered waveform in native byte order. In this example you would set up the default audio playing mechanism in `siteinit.scm' as follows

(Parameter.set 'Audio_Method 'Audio_Command)
(Parameter.set 'Audio_Command "adplay -raw -r $SR $FILE")

For Audio_Command method of playing waveforms Festival supports two additional audio parameters. Audio_Required_Rate allows you to use Festivals internal sample rate conversion function to any desired rate. Note this may not be as good as playing the waveform at the sample rate it is originally created in, but as some hardware devices are restrictive in what sample rates they support, or have naive resample functions this could be optimal. The second addition audio parameter is Audio_Required_Format which can be used to specify the desired output forms of the file. The default is unheadered raw, but this may be any of the values supported by the speech tools (including nist, esps, snd, riff, aiff, audlab, raw and, if you really want it, ascii).

For example suppose you run Festival on a remote machine and are not running any network audio system and want Festival to copy files back to your local machine and simply cat them to `/dev/audio'. The following would do that (assuming permissions for rsh are allowed).

(Parameter.set 'Audio_Method 'Audio_Command)
;; Make output file ulaw 8k (format ulaw implies 8k)
(Parameter.set 'Audio_Required_Format 'ulaw)
(Parameter.set 'Audio_Command 
 "userhost=`echo $DISPLAY | sed 's/:.*$//'`; rcp $FILE $userhost:$FILE; \
  rsh $userhost \"cat $FILE >/dev/audio\" ; rsh $userhost \"rm $FILE\"")

Note there are limits on how complex a command you want to put in the Audio_Command string directly. It can get very confusing with respect to quoting. It is therefore recommended that once you get past a certain complex consider writing a simple shell script and calling it from the Audio_Command string.

A second typical customization is setting the default speaker. Speakers depend on many things but due to various licence (and resource) restrictions you may only have some diphone/nphone databases available in your installation. The function name that is the value of voice_default is called immediately after `siteinit.scm' is loaded offering the opportunity for you to change it. Voices are currently defined in `voices.scm'. Look there for alternatives. In the standard distribution no change should be required. If you down load all the distributed voices voice_rab_diphone is the default voice. You may change this for a site by adding the following to siteinit.scm or per person by changing your .festivalrc. For example if you wish to change the default voice to the American one voice_kd_diphone

(set! voice_default 'voice_kd_diphone)

Note the single quote, and note that unlike in previous versions voice_default is not a function you can call.

A second level of customization is on a per user basis. After loading `init.scm', which includes `sitevars.scm' and `siteinit.scm' for local installation, Festival loads the file `.festivalrc' from the user's home directory (if it exists). This file may contain arbitrary Festival commands.

For example a particular installation of Festival may set Spanish as the default language by adding

(language_spanish)

in `siteinit.scm', while a user may wish their version to use Welsh by default. In this case they would add

(language_welsh)

to their `.festivalrc' in their home directory.

5.4 Checking an installation

Once compiled and site initialization is set up you should test to see if Festival can speak or not.

Start the system

$ src/main/festival
Festival Speech Synthesis System 1.2.1 September 1997
Copyright (C) University of Edinburgh, 1996,1997. All rights reserved.
For details type `(festival_warranty)'
festival> ^D

If errors occur at this stage they are most likely to do with pathname problems. If any error messages are printed about non-existent files check that those pathnames point to where you intended them to be. Most of the (default) pathnames are dependent on the basic library path. Ensure that is correct. To find out what it has been set to, start the system without loading the init files.

$ src/main/festival -q
Festival Speech Synthesis System 1.2.1 September 1997
Copyright (C) University of Edinburgh, 1996,1997. All rights reserved.
For details type `(festival_warranty)'
festival> libdir
"/projects/festival/lib/"
festival> ^D

This should show the pathname you set in your `config/config_make_rules'.

If the system starts with no errors try to synthesize something

festival> (SayText "hello world")

Some files are only accessed at synthesis time so this may show up other problem pathnames. If it talks, you're in business, if it doesn't, here are some possible problems.

If you get the error message

Can't access NAS server

You have selected NAS as the audio output but have no server running on that machine or your DISPLAY or AUDIOSERVER environment variable is not set properly for your output device. Either set these properly or change the audio output device in `lib/siteinit.scm' as described above.

Ensure your audio device actually works the way you think it does. On Suns, the audio output device can be switched into a number of different output modes, speaker, jack, headphones. If this is set to the wrong one you may not hear the output. Use one of Sun's tools to change this (try `/usr/demo/SOUND/bin/soundtool'). Try to find an audio file independent of Festival and get it to play on your audio. Once you have done that ensure that the audio output method set in Festival matches that.

Once you have got it talking, test the audio spooling device.

festival> (intro)

This plays a short introduction of two sentences, spooling the audio output.

Finally exit from Festival (by end of file or (quit)) and test the script mode with.

$ examples/saytime

A test suite is included with Festival but it makes certain assumptions about which voices are installed. It assumes that voice_rab_diphone (`festvox_rabxxxx.tar.gz') is the default voice and that voice_kd_diphone and voice_don_diphone (`festvox_kdxxxx.tar.gz' and `festvox_don.tar.gz') are installed. Also local settings in your `festival/lib/siteinit.scm' may affect these tests. However after installation it may be worth trying

gnumake test

from the `festival/' directory. This will do various tests including basic utterance tests and tokenization tests. It also checks that voices are installed and that they don't interfere with each other. These tests are primarily regression tests for the developers of Festival, to ensure new enhancements don't mess up existing supported features. They are not designed to test an installation is successful, though if they run correctly it it most probable the installation has worked.


Go to the first, previous, next, last section, table of contents.