4. Installation

Flite consist simple of a set of C files. GNU configure is used to configure the engine and will work on most major architectures.

In general, the following should build the system

tar zxvf flite-XXX.tar.gz
cd flite-XXX
./configure
make

However you will need to explicitly call GNU make gmake if make is not GNU make on your system.

The configuration process build a file ‘config/config’ which under some circumstances may need to be edited, e.g. to add unusual options or dealing with cross compilation.

On Linux systems, we also support shared libraries which are useful for keeping space down when multiple different application are linked to the flite libraries. For development we strongly discourage use of shared libraries as it is too easy to either not set them up correctly or accidentally pick up the wrong version. But for installation they are definitely encouraged. That is if you are just going to make and install they are good but unless you know what LD_LIBRARY_PATH does, it may be better to use static libraries (the default) if you are changing C code or building your own voices.

./configure --enable-shared
make

This will build both shared and static versions of the libraries but will link the executables to the shared libraries thus you will need to install the libraries in a place that your dynamic linker will find them (cf. /etc/ld.so.conf) or set LD_LIBRARY_PATH appropriately.

make install

Will install the binaries (‘bin/flite*’), include files and libraries in appropriate subdirectories of the defined install directory, ‘/usr/local’ by default. You can change this at configure time with

./configure --prefix=/opt

4.1 Windows Support

4.2 Window CE Support

NOTE: as Windows CE is somewhat rare now, we do not guarantee this still works.

Flite has been successfully compiled by a number of different groups under Windows CE. The system should compile under Embedded Visual Studio but we not have the full details.

The system as distributed does compile under the gcc ‘mingw32ce’ toolchain available from http://cegcc.sourceforge.net/. The current version can be compiled and run under WinCE with a primitive application called ‘flowm’. ‘flowm’ is a simple application that allows playing of typed-in text, or full text to speech on a file. Files should be a simple ascii text files *.txt. The application allows the setting of the byte position to start synthesis from.

Assuming you have ‘mingw32ce’ installed you can configure as

./configure --target=arm-wince
make

The resulting binary is given in ‘wince/flowm.exe’. If you copy this onto your Windows Mobile device and run it, it should allow you to speak typed-in text and any ‘*.txt’ files you have on your device.

The application uses cmu_us_kal as the voice for default. Although it is possible to include the clustergen voices, they may be too slow to be really practical. An 8KHz clustergen voice with a reduced order to 13 gives a voices that runs acceptably on an hp2755 (624MHz) but still marginal on an AT&T Tilt (400MHz).

Building 8KHz clustergen voices is currently a bit of hack. We take the standard waveforms and resample them to 8KHz, then relabel the sample rate to be 16KHz. Then build the voice as normal (as if the speaker spoke twice as fast. You may need to have tune the F0 parameters in ‘etc/f0.params’. This seems to basically work. Then after the waveform is synthesized (still in the "chipmunk” domain) we then playit back at 8KHz. This effectively means we generate half the number of samples and the frames are really at 10ms. A second reduction is an option on the basic ‘build_flite’ command. A second argument can specify order reduction, thus instead of the standard 25 static parameters (plus its deltas) we can reduce this to 13 and still get acceptable results

./bin/build_flite cg 13
cd flite
make

Importantly this uses less space, and uses less time to synthesis. These SPEECH_HACKS in ‘src/cg/cst_mlsa.c’ are switched on by default when UNDER_CE is defined.

The reduced order properly extracts the statics (and stddev) and deltas (and stddev) from the predicted parameter clusters and makes it as if those were the sizes of parameters that were used to the train the voice.

4.3 PalmOS Support

NOTE: as PalmOS is somewhat rare now, we do not guarantee this still works.

Support for PalmOS was removed from 1.9, I no longer have any working PalmOS devices. But this section remains for people who do, but they may need to update something to make this work.

Starting with 1.3 we have initial support for PalmOS using the free development tools. The compilation method assumes the target device is running PalmOS 5.0 (or later) on an ARM processor. Following convention in the Palm world, the app that the user interacts with is actually a m68k application compiled with the m68 gcc cross compiler, the resulting code is interpreted by the PalmOS 5.0 device. The core flite code is in native ARM, and hence uses the ARM gcc cross compiler. An interesting amout of support code is required to get all this work properly.

The user app is called flop (FLite on Palm) and like most apps written by awb, is functional, but ugly. You should not let a short-sighted Scotsman, who still thinks command line interfaces are cool, design a graphical app. But it does work and can read typed-in text. The ‘armflite.ro’ resources are designed with the idea that proper applications will be written using it as a library.

The ‘flop.prc’ application is distributed separately so it can be used without having to install all these tools. But if you want to PalmOS development here is what you need to do to compile Flite for PalmOS and the flop application.

There are number of different application development environments for Palm, here I only describe the Unix based one as this is what was used. You will need the PalmOS SDK 5.0 from palmOne http://www.palmone.com/us/developers/. This is free but does require registration. Out of the lots of different files you can get for palmOne you will eventually find ‘palmos-sdk-5.0r3-1.noarch.rpm’, install that on your linux machine

rpm -i palmos-sdk-5.0r3-1.noarch.rpm

You will also need the various gcc based cross compilers http://prc-tools.sourceforge.net/

prc-tools-2.3-1.i386.rpm                
prc-tools-arm-2.3-1.i386.rpm
prc-tools-htmldocs-2.3-1.noarch.rpm

The Palm Resource compiler http://pilrc.sourceforge.net/

pilrc-3.1-1.i386.rpm

And maybe the emulator http://www.palmos.com/dev/tools/emulator/

pose-3.5-2.i386.rpm
pose-skins-1.9-1.noarch.rpm             
pose-skins-handspring-3.1H4-1.noarch.rpm 

Though as POSE doesn’t support ARM code, ‘Simulator’ does but that only works under Windows, POSE is only useful for debugging the m68k parts of the app.

Install these

rpm -i prc-tools-2.3-1.i386.rpm                
rpm -i prc-tools-arm-2.3-1.i386.rpm
rpm -i prc-tools-htmldocs-2.3-1.noarch.rpm
rpm -i pilrc-3.1-1.i386.rpm
rpm -i pose-3.5-2.i386.rpm
rpm -i pose-skins-1.9-1.noarch.rpm             
rpm -i pose-skins-handspring-3.1H4-1.noarch.rpm 

We also need the prc-tools to know which SDK is available

palmdev-prep

In addition we use Greg Parker’s PEAL http://www.sealiesoftware.com/peal/ ELF ARM loader. You need to download this and compile and install it yourself, so that peal-postlink is in your path. Greg was very helpful and even added support for large data segments for this work (though in the end we don’t actually use them). Some peal code is in our distribution (which is valid under his licence) but if you use a different version of peal you may need to ensure they are matched, by updating the peal code in ‘palm/’. We used version ‘peal-2004-12-29’.

The other palm specific function we require is par http://www.djw.org/product/palm/par/ which is part of the prc.tgz distribution. We use par to construct resources from raw binary files. There are other programs that can do this but we found this one adequate. Again you must compile this and ensure par is in your path. Note no part of par ends up in the distributed system.

Given all of the above you should be able to compile the Palm code and the flop application.

   ./configure --target=arm-palmos
   make

The resulting application should be in ‘palm/flop/flop.prc’ which can then be installed on your Plam device

   pilot-xfer -i palm/flop/flop.prc

Setting up the tools, and getting a working Linux/Palm conduit is not particularly easy but it is possible. Although some attempt was made to use the Simulator, (PalmOS 5.0/ARM simulator) under Windows, it never really contributed to the development. The POSE (m68k) emulator though was use to develop the flop application itself.

4.3.1 Some notes on the PalmOS port

Throughout the PalmOS developer documentation they continually remind you that a Palm device is not a full computer, its an extention of the desktop. But seeing devices like the Treo 600 can easily make one forget and want the device to do real computational work. PalmOS is designed for small light weight devices so it is easy to start hitting the boundaries of its capabilities when trying to port larger aplications.

PalmOS5.0 still has interesting limitations, in the m68k domain, int’s are 16 bit and using memory segments greater than 65K require special work. Quaint as these are, they do significantly affect the port. At first we thought that only the key computationally expensive parts would be in ARM (so-called armlets) but trying to compile the whole flite code in m68k with long/short distinctions and sub-64K code segment limitations was just too hard.

Thus all the Flite code, USEnglish, Lexicon and diphone databases actually are compiled in the ARM domain. There is however no system support in the ARM domain so call backs to m68k system functions are necessary. With care calls to system functions can be significantly limited so only a few call backs needed to be written. These are in ‘palm/pocore/’. I believe CodeWarrior has better support for this, but in this case we rolled our own (though help from other open source examples was important).

We manage the m68k/ARM interface through PEAL, which is basically a linker for ARM code and calling mechanism from m68k. PEAL deals with globals and spliting the code into 65K chunks automatically.

Flite does however have a number of large data segments, in the lexicon and the voice database itself. PEAL can deal with this but it loads large segments by copying them into the dynamic heap, which on most Palm device is less than 2M. This isn’t big enough.

Thus we changed Flite to restrict the number of large data sgements it used (and also did some new compression on them). The five segments: the lts rules, the lexical entries, the voice LPC coefficients, the voice residuals and the voice residual index are now treated a data segments that are split into 65400 sized segments and loaded into feature memory space, which is in the storage heap and typically much bigger. This means we do need about 2-3 megabyte free on the device to run. We did look into just indexing the 65400 byte segments directly but that looked like being too much work, and we’re only going to be able to run on 16M sized Palms anyway (there aren’t any 8M ARM Palms with audio, expect maybe some SmartPhones).

Using Flite from m68k land involves getting a flite_info structure from flite_init(). This contains a bunch of fields that be set and sent to the ARM domain Flite synthesizer proper within which other output fields may be set and returned. This isn’t a very general structure, but is adequate. Note the necessary byte swapping (for the top level fileds) is done for the this structure, before calling the ARM native arm_flite_synth_text and swapped back again after returning.

Display, playing audio, pointy-clicky event thingies are all done in the m68K domain.

4.3.2 Using the PalmOS

There are three basic functions that access the ARM flite functions: flite_init(), flite_synth_text() and flite_end().

This document was generated by Alan W Black on December 24, 2014 using texi2html 1.82.