File: INSTALL

package info (click to toggle)
festival 1.2.1-6
  • links: PTS
  • area: non-free
  • in suites: hamm
  • size: 2,824 kB
  • ctags: 3,072
  • sloc: cpp: 21,428; lisp: 8,298; ansic: 1,498; sh: 722; makefile: 468; perl: 87
file content (507 lines) | stat: -rw-r--r-- 24,820 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
Installation
************

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
        * Sun Sparc Solaris 2.5.1: GCC 2.7.2, GCC 2.6.3, SunCC 3.01,
          SunCC 4.1

        * Sun Sparc SunOS 4.1.3: GCC 2.7.2

        * Intel SunOS 2.5.1: GCC 2.7.2

        * FreeBSD for Intel 2.1.7 and 2.2.1: GCC 2.7.2, GCC 2.6.3

        * Linux (2.0.30) for Intel (RedHat 4.1): GCC 2.7.2

        * DEC Alpha OSF1 3.2: GCC 2.7.2

        * Windows NT 4.0: GCC 2.7.2-970404 (from Cygnus GNU win32 b18)
     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. *Note 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/

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.

   An initial attempt at compile the system under Microsoft's Visual C++
V5.0.  The speech tools compile under Windows95 or (hopefully) Windows
NT with Visual C++ using the Microsoft `nmake' make program. 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 directory.  This has only been 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
`VCMakefile's will not contain dependency information for the .cc files.

   In order to compile from the command line using Visual C++ you have
to have run the command vcvars32 to set up some environment variables.
See the VC++ documentation for more details.

   With the `VCMakefile's, and optionally `vc_make.depend' files, you
should be able to compile the speech tools by doing
     nmake /nologo /fVCMakefile
   The library, all of the executables in main and the test programs in
testsuite will compile. The VCMakefiles do not make the links in the
bin directory or run the testsuite and there is no facility for
remakeing the dependencies.

   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 this hasn't actually been
tested.

   We fell that if you wish to compile the system under Visual C++ then
with a little more work it is possible though it is more likely that the
Cygnus GNU win32 port will work.

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.

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.0 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.0 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.