6.2 Configuration

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

The system now supports the standard GNU configure method for set up. In most cases this will automatically configure festival for your particular system. In most cases you need only type

gmake

and the system will configure itself and compile, (note you need to have compiled the Edinburgh Speech Tools speech_tools-1.2.2 first.

In some case hand configuration is required. All of the configuration choices are kept in the file config/config.

For the most part Festival configuration inherits the configuration from your speech tools config file (../speech_tools/config/config). Additional optional modules may be added by adding them to the end of your config file e.g.

ALSO_INCLUDE += clunits

Adding and new module here will treat is as a new directory in the src/modules/ and compile it into the system in the same way the OTHER_DIRS feature was used in previous versions.

If the compilation directory being accessed by NFS or if you use an automounter (e.g. amd) it is recommend to explicitly set the variable FESTIVAL_HOME in config/config. The command pwd is not reliable when a directory may have multiple names.

There is a simple test suite with Festival but it requires the three basic voices and their respective lexicons installed before it will work. Thus you need to install

festlex_CMU.tar.gz
festlex_OALD.tar.gz
festlex_POSLEX.tar.gz
festvox_don.tar.gz
festvox_kedlpc16k.tar.gz
festvox_rablpc16k.tar.gz

If these are installed you can test the installation with

gmake test

To simply make it run with a male US English voice it is sufficient to install just

festlex_CMU.tar.gz
festlex_POSLEX.tar.gz
festvox_kallpc16k.tar.gz

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.

Although we have tried very hard to ensure that Festival compiles with no warnings this is not possible under some systems.

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 Linux a warning at link time about reducing the size of some symbols often is produced. This is harmless. There is often occasional warnings about some socket system function having an incorrect argument type, this is also 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 libraries 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 source trees with VCMakefiles somewhere visible from Windows, you need to copy peech_tools\config\vc_config-dist to speech_tools\config\vc_config and edit it to suit your local situation. Then do the same with festival\config\vc_config-dist.

The thing most likely to need changing is the definition of FESTIVAL_HOME 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 automatically 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.

Most of the modules src/modules are actually optional and the system could be compiled without them. The basic set could be reduced further if certain facilities are not desired. Particularly: donovan which is only required if the donovan voice is used; rxp if no XML parsing is required (e.g. Sable); and parser if no stochastic paring is required (this parser isn’t used for any of our currently released voices). Actually even UniSyn and UniSyn_diphone could be removed if some external waveform synthesizer is being used (e.g. MBROLA) or some alternative one like OGIresLPC. Removing unused modules will make the festival binary smaller and (potentially) start up faster but don’t expect too much. You can delete these by changing the BASE_DIRS variable in src/modules/Makefile.