As the start up time for CHATR can be prohibitive, it is possible to use it in server mode. This means that a version of CHATR continuously runs until a client program accesses it. A version of the server is then forked and the client asks the server to perform some synthesis. If the server already has a number of databases loaded, the client need not wait for them to be reloaded. The time between starting and output of the first waveform is therefore greatly reduced.
In this scenario the server provides four speakers (MHT, fmp559, f2b, and wnc600). Assume it is to run on terminal as71 using the default port (2234). In this case we create a file which when executed loads the speakers. We call it `server.ch', and it contains
(speaker_MHT)
(speaker_f2b)
(speaker_fmp559)
(speaker_wnc600)
Given the current state of our network this will take between 10 and 30 seconds to load. To start the server type
chatr --server server.ch
This will load-in the databases and then listen on a socket for potential clients. If you get the error `CHATR: Can't bind to socket' the most likely problem is that there is already a CHATR server running on that machine. After killing a server you may have to wait several moments before the socket becomes free again.
NOTE: Anyone on the network may contact this server. Hence there is a potential security problem. However, only a small set of functions are actually available, so intruders (hopefully) cannot actually do any damage (except use our resources). This mode is in fact more secure than the way we normally run X windows servers.
The client side must connect to the server and ask for synthesis.
The easiest way to do this is using the program chatr_pipe.
This will read text from standard input and (by default) produce 8kHz
ulaw data on standard out. Assuming the above server is running, we
can type
echo Hello there | chatr_pipe -h as71 >/dev/audio
As this is relatively low quality output (ulaw) you may also get the CHATR server talk directly to a DATLINK audio server. Using the following command
echo Hello there | chatr_pipe -h as71 -d
Note that in this situation the client does not know when the synthesis has finished. Care must therefore be taken that not too many requests are sent to the server at once.
Some applications seem to be happy to send off synthesis requests not caring if they complete or not. You may therefore have to restrict the number of requests that need to be dealt with on the server end by limiting the number of clients that can be connected at any one time. For example, to limit the number of simultaneous clients to 2, add the following line to the start of your `server.ch' file
(set chatr_max_clients '2)
On the client side we can get multi-speaker (and multi-language) synthesis by including speaker directives in the incoming text. For example, given a file called `text' containing the following
@f2b Good Morning, how can I help you? @wnc600 I'd like
to get to the conference center. @f2b The taxi is the
easiest way.
We can get the multi-speaker file synthesized using the command
cat text | chatr_pipe -h as71 -d
More complex client/server relationships are possible depending on
the desires of the user. Arbitrary CHATR commands may be sent
to the server (the chatr_pipe command just sends some initial
commands and the text). If you talk to the server directly via
telnet or similar, you may execute any commands that are in the list
which is set in the variable chatr_secure_functions. In
`server.ch' you may define any commands, add them to
chatr_secure_functions and then have a client program send
those commands.
A much more complex client/server example is given in `lib/examples/saymail.ch'. This is the server side of a telephone-based mail reading program. The client side was written in tcl for a private internal telephone service. Although by no means comprehensive, this example does show some of the potential power of CHATR.
Suppose you wish to make a binary distribution of CHATR, or in this specific example, a CDROM version. As CHATR must know it's library directory (normally specified at compile time), a binary distribution must have a way of specifying it's library directory at run time. In addition, all other path names in CHATR must be dependent on this specified library directory.
Note binary distributions must not include GNU readline, or if they do full sources must be included in the distribution (as would be the case in a CDROM version). Also note that some binaries will contain proprietary code when compiled (from ESPS and HTK) because they are linked with libraries, although their source does not contain any proprietary code. (However, note that `chatr/db_utils/HCode_cube.c', created during compilation, is a modification of the HTK HCode.c source.)
When compiled, the default distribution does not have all paths dependent of the library path. This is because most developers do not wish to copy the databases and dictionaries to their own directory.
For a CDROM version the following is recommended
CHATR_USRLIBDIR in `chatr/src/include/ch_config.h'
to `/cdrom/chatr/lib/data/'.
In `chatr/lib/data/' create the file `site_paths.ch' for local path setting. Add the following lines
(set main_db_dir (strcat (car load-path) "/../dbs/"))
(set main_dic_dir (strcat (car load-path) "/../dic/"))
(set site_speakers_file "cdrom_speakers.ch")
This causes the main variables to be fully dependent on the library path. Thus when changed at run time, these values will change too.
Next create the file `cdrom_speaker.ch' in
`chatr/lib/data/'. List the database speakers you have added
to `chatr/lib/dbs/'. Add the defspeaker command so it
is dependent on main_db_dir, for example
(defspeaker "f2b" (strcat main_db_dir "f2b/"))
(defspeaker "wnc600" (strcat main_db_dir "wnc600/"))
(defspeaker "MHT" (strcat main_db_dir "MHT/"))
(defspeaker "fmp559" (strcat main_db_dir "fmp559/"))
(set speaker_default speaker_f2b)
(set espeaker speaker_f2b)
(set jspeaker speaker_MHT)
Also define the default speaker, and default speakers for text-to-speech.
When building a CDROM, it is desirable to build-in binaries for
multiple architectures. CHATR has two classes of executables,
those for users of chatr or chatr_pipe, and those used
by CHATR. These are kept in the `etc' directory, together
with the audio spooler and X windows utterance inspector. If the
make variable CH_OSTYPE is set during compilation (in
`src/include/config.make.rules', CHATR's internal
executables will be saved in the directory `lib/etc/CH_OSTYPE'
For each desired architecture, make the binaries from the
`chatr/src/' directory. You should change CH_OSTYPE for
each architecture type. Also remember to make clean (after
changing CH_OSTYPE) and make depend for each new
architecture. Once compiled, move the user binaries to an
architecture dependent directory using the commands
mkdir -p ../../chatr/bin/sunos
mv main/chatr ../../chatr/bin/sunos
mv main/chatr_pipe ../../chatr/bin/sunos
The internal executables will be compiled automatically into their appropriate directory.
Note that although databases include a binary index, the binary index is architecture independent. Byte swapping will occur automatically when required. Tests on timing for the cost of byte swapping show that it is almost free and less than 1% of the time required to actually read the data. So there is little requirement that the binary index (or the waveform files themselves) be in the native byte order of the machine they are actually running on.
On completion of compiling multiple versions of CHATR, there should be user binaries in `chatr/bin/CH_OSTYPE/', and CHATR internal files in `chatr/lib/etc/CH_OSTYPE/'. If the CDROM is mounted on a machine on `/cdrom/', users should be able to run the synthesizer as follows
/cdrom/chatr/bin/<OSTYPE>/chatr
If the CDROM is not mounted under `/cdrom/', but under some other directory, the library directory will need to be set in CHATR. In that case CHATR may be called as follows
<MOUNTPNT>/chatr/<OSTYPE>/chatr --libdir <MOUNTPNT>/chatr/lib/data/
There are at least two problems with the above description. First,
binaries in `chatr/db_utils/' are not dealt with in an
architecture independent way. The binaries in `chatr/db_utils/'
will be those for the last architecture built. The second major
problem is that the kana/kanji conversion program is not included in
such a CDROM. It is assumed there is a program called kan2rom
which reads in kana/kanji and produces romaji labeled with accents
and break indices.
Go to the first, previous, next, last section, table of contents.