| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |