CHATR has a number of requirements to enable the system to be compiled and installed.
In rough order of necessity these are
ANSI C compiler (e.g. gcc)
GNU Make
include directive in Makefiles, you need a
make that can support it. Sun's make does not. There
are many `makes' available and they vary quite widely between
different machines. Be sure to acquire a common one which is usable
on all machines.
makedepend
makedepend. `Makedepend' is available as part of the X11R5
distribution and usually installed with it. Unfortunately there are
a number versions of `makedepend' and they are all subtly
incompatible.
GNU Readline library
NIST sphere, speech file header library
GNU test, GNU RCS
NCD NetAudio
DAT-Link
naplay. The direct method has the
advantage of faster access, no spurious output (naplay always
prints a messages), and no worry about finding the pathname of
naplay at run time.
DEC AudioFile
kan2rom
kan2rom is installed. This converts kana/kanji to romaji,
with breaks and accents. In most installations it is a proprietary
program from KDD. A free alternative using kakasi is
partially supported but the results are not as good - accents are not
marked. The shell script in lib/etc/k2r is the interface. If
a version of kan2rom is not available, you should copy
`k2r' as kan2rom. The function poor_jtts uses the
k2r script by default.
XMG
XWAVES
ESPS functions
HTK
HCode and HCopy are required when building new
databases. Note the source for `HCode.c' is required, as a new
copy of HCode is created and compiled. A patch is provided
with CHATR. Once the database is created, HTK is not required
and no Entropic licensed code exists within CHATR.
fz_track
fz_track. This
is from an intonation package developed within ATR. It would be much
more sensible to use ESPS's get_f0 to extract pitchmarks as it
is probably better, and we already use it in database creation.
However, as we have not fully investigated PSOLA (the current sole
user of pitch marks), we are yet to determine the best way to
generate pitchmarks.
Only the first two of this list are mandatory; plus an ANSI C compiler and GNU make. The others may be left out at compile time, however GNU readline and NIST headers are highly recommended. See the file `REQUIREMENTS' in the distribution for more details about where to obtain these programs if you do not already have them.
First, apologies should be made for the complexity of installation and configuration. This requires further work to make it easier.
The source for CHATR is managed by RCS, a system that controls software versions. At every major (or possibly minor) release, a gzipped tar file is produced containing all the source code. For non-development use, this file may be copied and unpacked. For development, your copy of the code should be linked to the library version so updates may be copied out and your changes easily integrated back into the central library.
NOTE: This may change in later versions, where CVS will be the sole method of accessing and updating the CHATR core distribution.
In ATR ITL, a development copy of the source should be copied using the following method.
The master library copy of the CHATR source is in `/DB/PI/chatr/'. First create a directory for your personal copy of the code. For example, issue the commands
cd
mkdir src
cd src
mkdir chatr
cd chatr
The library copy of the source may be copied with three simple commands. First, the necessary directories are created using the command
/DB/PI/chatr/utils/mkchatrdirs
Then put links in each directory to the appropriate RCS depository directories using the command
/DB/PI/chatr/utils/mkchatrrcs
Finally, a full copy of the code is required. The RCS system will automatically check out a read-only version of the system given the command
make update
Note this must be GNU `make'.
Many messages will be generated, some of which look like errors. This is because when a file is not found, an error message is generated, but the file will then be automatically checked out from the RCS library.
An alternative method of installation is from a `.tar.gz' file. This must be used when the installation is remote from the RCS library. As an example, if you are installing CHATR version 0.8, unpack the archive with the command
cd ~/src
tar zxvf chatr-0.8.tar.gz
For later versions simply replace the `0.8' with the number of the version you are installing.
Note that if you do not have GNU `tar' the above will not work. In that case, either get GNU tar installed or use the alternative
cd ~/src
gunzip chatr-0.8.tar.gz
tar xvf chatr-0.8.tar
The third method of installation will eventually replace the RCS method. CVS, a more general version of RCS, can be used to give you your own read/write version of the CHATR source. CVS will also allow you to check in your changes if you wish, but will not restrict others from working on the same files. This method is good when a system becomes stable and people usually would not be editing the same files.
If using the `bash' shell, you may checkout a CVS version with the command
export CVSROOT=/DB/PI/CVSROOT #
cvs checkout chatr
If using the `csh' shell the command is
setenv CVSROOT /DB/PI/CVSROOT #
cvs checkout chatr
This will `checkout' a read/write copy of the whole source tree in the current directory called `chatr'.
The CHATR source directory tree is
------ data/
|------ dbs/
------ lib/ ------|------ dic/
| |------ etc/
| ------ examples/
|
|------ db_utils/
|
| ------ arch/
| |------ audio/
chatr/ ---|------ utils/ |------ chatr/
| |------ chinspect/
| |------ display/
| |------ duration/
|------ doc/ |------ file/
| |------ hlp/
| |------ include/
| |------ input/
------ src/ ------|------ intonation/
|------ lex/
|------ lib/
|------ lts/
|------ main/
|------ phoneme/
|------ phrase/
|------ ruc/
|------ synth/
|------ text/
------ udb/
See section CHATR Source File Locations, for lists of what files are kept in each directory.
.
doc/
lib/
lib/data/
lib/etc/
CH_OSTYPE is set at compile time, these files
will be kept in separate sub-directories such that the library
directory may be shared between architectures.
lib/examples/
lib/dic/
lib/dbs/
main_db_dir (from which many database directories are derived)
set to /DB/PI/chatr/lib/dbs/,
utils/
db_utils/
src/
src/arch/
src/audio/
src/chatr/
src/chinspect/
src/display/
src/duration/
src/file/
src/hlp/
src/include/
src/input/
src/intonation/
src/isard/
src/formant/
src/lex/
src/lib/
src/lts/
src/main/
src/nuutalk/
src/nuutalkhi/
src/phoneme/
src/phrase/
src/ruc/
src/synth/
src/taylor/
src/text/
src/udb/
Every user of the CHATR source has their own configuration. This
is set by two files in `src/include/', `ch_config.h' and
`config.make.rules'. If you used make update, personal
default copies of these files will already exist. If you are
unpacking from an archive file, you must obtain copies by issuing the
commands
cd src/include
cp config.make.rules-dist config.make.rules
cp ch_config.h-dist ch_config.h
chmod +w ch_config.h config.make.rules
You will most likely have to edit each of these files.
C-source level configuration is done in `ch_config.h'.
This file contains a number of C preprocessor definitions. If you do
not wish to have any of these options, comment them out. An
explanation above each explains their function. Most important is
the definition of CHATR_USRLIBDIR, which defines where
CHATR will find the CHATR library files. It should end in
`/lib/data'. If you are going to install the library other than
where the source is, you should change this to point to that
installation directory. Otherwise it should be an absolute path-name
to that in the source. It is possible to change this at run time
(and even add new library directories in addition to this one),
however it makes your life simpler to change this before compilation.
CHATR developers should make this variable point to their own
version of the CHATR library that they have just unpacked.
The second configuration file `config.make.rule' contains all the configuration information for the Makefiles in the system, i.e. library and include directories for sub-systems as well as compilers and options.
The variable CH_OSTYPE in `config.make.rules' may be
optionally set to the name of the system your are compiling under.
If set, CHATR internal executables will be compiled (and copied
in case of scripts) into a sub-directory in lib/etc/CH_OSTYPE
so that different architectures may share the same library directory.
If CH_OSTYPE is unset the internal executables are left in
`lib/etc'.
Now that you have configured the system, change directory to the main source directory (the one above `include/'). Enter
cd ..
It is now necessary to build the complete Makefiles and the dependencies between C files and headers. This need only be run once, or when major changes have been made to source files.
make depend
Many messages will be given including ones that look like errors.
These may be ignored. Note that when recompiling for a new
architecture you must use make clean and make
depend.
The whole system may now be compiled using
make
After some time the CHATR executable will be built in the `main/' directory. As a rough guide, it takes around 10 minutes on a Sparc10. However, the building of archive files can take a lot longer if the distribution is being accessed by NFS. During this process, the X-windows display program and audio spooler will also be built, but in the `lib/etc/' directory.
The whole compiled system and source will require around 10-15 megabytes of disk space.
You will need to ensure that there are lexicons and databases available to CHATR. In the standard distribution, the path names point to lexicons and databases in the ITL filesystem. If your installation is elsewhere, you will need to install lexicons and databases. See section Installing Speech Synthesis Databases, for information about installing databases. See section Customizing an Installation, for customization details.
You now have a fully compiled CHATR system.
To hear CHATR talk, ensure you have a valid `.chatrrc' that defines your audio device. You can get a default version from `lib/data/default.chatrrc'. Copy this to your home directory , rename it `.chatrrc', and edit it to reflect the audio hardware that you have attached to your machine. To test the system by producing an output, go to the `src/' directory and enter the commands
main/chatr -tts ../lib/examples/chatr_intro
main/chatr -jtts ../lib/examples/chatr_jintro
If you get the error
Sorry, can't talk to audio device: 0
then you have not properly informed CHATR about you audio hardware. Check your `.chatrrc' file. See section Audio Setup - Software, for editing details.
There are a number of compilation errors whose solution is not immediately obvious. This section details some of the more common ones.
In general the system is compiled with option -Wall, which
gives warnings for most problems. Apart from optional subsystems,
CHATR and the window inspector code should compile with no
warnings except in the following conditions. Some system functions
(e.g. bzero, memcpy, random, the entire
stdio library (and most of the socket functions) under SunOS)
do not have function prototypes and hence give warnings about
implicit definitions. CHATR cannot give prototypes to system
functions. This is actually a bug in the operating system and not in
CHATR. You will have to live with these errors.
Occasionally there are functions defined which are not used. These may be used in the future so have been left in.
If you get an error about an implicit definition of a CHATR function, you probably have not included the appropriate include file or possibly mis-named the function. Search for the function in `include/*.h' and include that file. Locate and correct any typos.
If you get `Undefined symbol' at link time for any of P_Error,
P_Warning, P_Message, etc, you have forgotten to
include `interface.h' in a source file. There should have been
a warning when that file was produced saying the P_Error or
whatever is implicitly declared.
If you get `dereferencing pointer to incomplete type', then again you have forgotten to include the `.h' file that defines some structure.
CHATR currently compiles and runs under SunOS, Solaris, HP-UX, DEC alpha, SGI, linux and FreeBSD. These are quite varied Unix systems, with different byte order, different word size, and different BSD/SYSV histories. Therefore CHATR should be portable to other Unix's with few problems.
Byte order is dealt with automatically within the system. The byte order of the machine being compiled on is determined by the expression in `src/include/general.h'. Database waveform files have their byte order declared so CHATR can swap them to the installation's native byte order if required. The only other binary files in the system are the database index files. A `magic number' at the start of these files allows CHATR to determine if the byte order of the machine used to create the file is different from that of the machine reading the file. If so, byte swapping occurs. Floating point numbers are also swapped, although this only occurs if reading database index files. It is possible that the algorithm used for swapping floats may need to be changed if CHATR is ported to some new architectures.
However, there are some other specific points that are more likely to be problems when porting to new systems.
First, the existence of the basic floating point routines differ from
machine to machine, specifically: nint, isnormal and
isinf. nint appears on some systems and not on others.
It is defined as a macro in `src/include/general.h' for those
systems that do not have it. You may need to add to the
ifdef's in that file for new systems. Likewise the
definitions for the other floating point functions. These are
defined in `src/arch/sysdep.c' and may require new
ifdef's.
Wherever possible, system-dependent functions are in `src/arch/sysdep.c' and hence only that file should need to change.
When using compilers other than gcc, you should choose the vendor's ANSI C options. This is in fact not always well defined. (gcc also has this problem.) Of the two non-gcc version of ANSI C tested, extra defines were necessary to get CHATR to compile (or even to get trivial programs to compile for that matter).
Under HPUX, the non-gcc native C compiler definitions in `src/include/config.make.rules' should look like
CC = cc
OPT = -Aa -O -D_HPUX_SOURCE -D__hppa__
With IRIX5.3 (on SGI's), the native C compiler options should look like
CC = cc
OPT = -ansi -O2 -mips2 -D_SVR4_SOURCE
In order for many people to develop CHATR at the same time, it is necessary to ensure that two people cannot change the same file at the same time. The source code control system RCS (Revision Control System) aids this. If one person is editing a source, no other developer may do so. Thus all sources are by default read-only. When a file is checked-out by a developer, they may change it but no other developer may check it out at the same time. When a developer is finished they may check-in the file thus allowing others to check it out. Files may be checked in and out using the RCS commands
ci <file>
co -l <file>
It is highly recommended that developers who have access to EMACS use the EMACS functionality to check-out files (and sometimes to check-in files too).
To check-out a file in EMACS, simply load it into a buffer using the usual C-x C-f. C-x C-q will automatically check-out a file for editing.
Checking-out is usually done file-by-file as required, but once a stable state is reached developers can check-in all of their checked-out code at once. To check-in all code below the `src/' directory, while in that directory type
make checkin
You will be prompted for a comment for each file that is checked-in. As no comments are actually used, you may simply type `. RET' for each file.
Alternatively, to check-in a single file in EMACS, type C-x C-q in the buffer and then (ignoring the request for a comment), type C-c C-c.
Occasionally you will wish to update your version of the code with other people's recently checked-in versions. To do this, in the CHATR root directory type
make update; make update
The reason it is required twice is that if new files have been added
to the distributions, you need to first check-out the Makefile
which names the new files, then update again to take into account the
new named file.
NOTE: EMACS can get confused (as can users) when checking-in versions of code. It is safest to exit EMACS (or at least kill all buffers editing CHATR code) immediately after checking-in code.
NOTE: It is also thoroughly recommend that you type
make update after checking-in your code.
NOTE: As UNIX machines have their own clock that may be a
few seconds (or possibly minutes) different, and that times of files
are used to decide if files need updates or not, it is possible that
files may not be automatically checked-in even when they have been
changed. This happens if a file is checked-out and changed and then
saved such that its local time stamp is earlier than the time stamp
on the library copy (pretty fast editing - or shoot your system
administrator if the clock is that far out!). In this case, edit
the file again giving it a newer time stamp. Or check it in by hand
using either EMACS C-x C-q or the command ci <file>.
CHATR is unlikely to be of much use as a speech synthesis system unless it can actually talk. Our highest quality speech comes from databases of natural speech. Due to their size and varying distribution rights, these databases are not included in the core CHATR source distribution. Such speech databases can be made automatically from waveform files and label files. See section Making a Speech Synthesizer Database, for more information.
However, copying an existing database is perhaps easier. Standard
databases allow easy packing and transportation. From a database
directory, the command db_utils/make_tar will make a tar'd,
gzipped file containing all the necessary files in a speech
database. Four levels of packing are provided.
bin
binx
src
rsrc
asrc
To install any of the above `tar' files simply unpack them in a
directory and then declare to CHATR where they are using the
defspeaker command. See section Defining a Speaker, for more
details.
Before a speaker can be used, the name and directory location must be
made known to CHATR. This is done using the defspeaker
command. The defspeaker command takes two arguments, a
database name and a directory. The name should be the name of the
database as defined in the `db_description' file. The second
argument should be the full path name of the database directory (i.e.
the directory containing the subdirectory `index/'. The path
name must be suffixed with a slash `/'. Both arguments should
be in double quotes. For example
(defspeaker "Me" "/mypath/data/Me/")
Expressions which evaluate to atoms are allowed.
defspeaker commands may be put in your own `.chatrrc' file
(perhaps defining speakers for users of a particular installation), or
simply typed to the command interpreter. See section Customizing an Installation, for details on how to customize an installation.
Not all installations of CHATR will have the same resources available. Different databases and different lexicons are two major areas that may change. This section describes how to customize a particular installation.
CHATR cannot run properly without accessing its own library directory. The path name for the default library directory is defined at compile time in the `ch_config.h' file, but if for some reason it is not possible to recompile, the library file may be specified on the command line when CHATR is called.
chatr --libdir /usr/local/chatr/lib/data/
Note the library directory should point to the `data/' directory within the CHATR distribution.
Unless CHATR is started with the -q option, the first thing it does is to load `init.ch' from the library directory. Although this file may be edited to contain custom requirements, there are two files available nore appropriate (and safer!) for that purpose: `site_paths.ch' and `site_init.ch'.
If the file `site_paths.ch' exists in the library directory it
will be loaded. Creating this file gives a user the opportunity to
set some basic path names required during normal startup. Use the
command set to define these. In particular
site_speakers_file
defspeaker commands) for the
databases available in this installation. If it is not set, the file
`itlspeakers.ch' will be loaded, threrby defining the speakers
that are available in the ATR ITL filesystem. If you wish the ITL
speakers to be defined plus your own, you could create your
own speaker definition file and include `itlspeakers.ch' file in
that. At a minimum the site speakers file must define: a default
speaker (speaker_default); and default speakers for English
tts (espeaker) or Japanese tts (jspeaker), if required.
main_db_dir
make_dic_dir
If the above values are to be changed from the default, they must be set before any futher initialization occurs.
More general site specific initialization may be done in the file `site_init.ch'. If this file exists it will be loaded. It may contain any CHATR commands that are required for a specific installation.
As mentioned at the beginning of this section, customization is also possible by editing the `init.ch' file directly. However, care must be taken, especially if non-default directory path-names are yet to be declared in `site_paths.ch'.
Go to the first, previous, next, last section, table of contents.