Next Previous Contents

2. Architecture

To avoid a trade-off between efficiency and configurability Epos uses the client-server model of operation. All interesting processing happens at the server, so the name Epos really refers to the background server process and not to the clients. (In fact, some users who use Epos for production work wrote their own specialized clients.)

When you start Epos, it goes through the initialization phase, in which it interprets the server command line and accesses the file system to read a number of configuration files (in the order of hundreds in the distributed configuration); most of this process consists of setting options and of parsing transformation rules for the text-to-speech conversion for each configured language. It is possible to configure Epos so that after the initialization phase it doesn't use the file system at all; by default the loading of a few types of information is delayed up to the point when that information is first used. Almost all of the configuration is provided through text files which are parsed into an efficient internal form.

After the initialization phase is over, Epos becames an OS service or daemon, listening on a TCP port for new TTSCP connections; TTSCP is the only protocol Epos uses for passing both control information and data. There is no principial limit on the number of simultaneously connected clients or served requests and the configuration structures for all clients are fully independent.

The most common task for Epos is a text to speech conversion. Every client can decide (requesting different TTSCP streams) whether the resulting speech should be sent back through a data connection or whether the server should pass it directly to the operating system audio output interface. Apart from debugging and logging output this is the only exception from the rule that TTSCP is the only output channel for Epos (and basically the only input channel, too).

This is the minimum you have to know about Epos to run it. The following sections are harder to read, but they include all the details. The sections on the rules and especially on the options describe both the overall structure of Epos configuration and the details about specific functionality. The section on TTSCP is very stable (we do not attempt to keep Epos backwards compatible in details, but we do keep TTSCP backward compatible) and includes everything you need to write your own TTSCP client. The sections on administration (logging messages and security issues) summarize relevant information from previous sections. The section on development is a starting point for contributing to the Epos project and also includes some technical details concerning portability.


Next Previous Contents