TTSCP is a client-server connection-oriented, both human- and machine-readable communication protocol, remotely similar to the File Transfer Protocol in spirit. TTSCP is offered as a standard interface for controlling generic speech processing applications, not only Text-To-Speech ones. It is primarily designed to run atop TCP, but any reliable connection-oriented underlying protocol should theoretically work as well.
The server awaits new connections on a single TCP port.
There are two types of connections: control connections
used to issue commands by the client and to return status
information, such as completion messages by the server,
and data connections used to transfer the actual data.
Immediately after the underlying connection is opened,
the server transmits a session header (see below)
and treats the connection as a control connection, until
the data command is issued by the client, causing
it to become a data connection.
Every TTSCP connection (both a control one and a data one) obtains a connection handle from the server inside the session header. This handle is a string of alphanumeric characters which uniquely identifies the connection and which also serves as an access token for it. Other connections can use such a handle to interrupt a control connection's task in progress, to disconnect any connection, to process data received from a data connection etc.
A TTSCP session is a sequence
of commands, their results and referenced data lasting
from setting up the control connection until its disconnection
or the data command.
Any party may quit the session at any time, but must advise
the other one either by the done command (the client)
or by a 600 response code or higher (the server).
If a done command is sent before a preceding command
has completed, the server will proceed with the
preceding commands. If a 600 or higher error code
is received as a response to a command and subsequent commands
have already been sent by the client, they will not be executed.
A data connection may be silently disconnected by the client
at any time. To allow reliable disconnection detection by the
server, every data connection is attached to an already
existing control connection (as specified with the data
command) and it will be automatically disconnected when
the control connection is disconnected. This attachment relation
doesn't prevent other control connections from referencing this
data connection using its handle, it only limits its lifetime.
The session header (as sent before a TTSCP session starts)
is a sequence of lines terminated with an empty line (two consecutive
linefeed characters with no whitespace intervening). The first line
shall exactly match the string TTSCP spoken here; the clients
are strongly encouraged to use this string to identify the protocol.
The following lines, except the terminating (empty) one each contain
a TTSCP header keyword terminated by a colon and a single space
and the value associated with the keyword. The client may choose
not to use these values at all, or to scan only for some header
keywords. The last keyword in the header shall be the handle
keyword.
A typical TTSCP session looks like this, with client commands unindented and server responses indented.
TTSCP spoken here
protocol: 0
extensions:
server: Epos
release: 2.4.6
handle: O29-m2UZ
user user@host.domain.net
452 user not found
setl some_option on
200 OK
strm $zC-4EEl0:raw:rules:diphs:synth:/dev/dsp
200 OK
appl 34
112 started
122 total bytes
3622
123 written bytes
3622
200 OK
done
600 goodbye
The "user" and "done" commands may become mandatory, the rest may be freely used between them. For the interaction with a human, the "help" command is available.
It is legal to use "anonymous" instead of the address in the user command: "user anonymous". It is also legal to switch users with additional user commands. This may cause context switches.
It is advised to check the greeting string received to begin in "preTTSCP" or "TTSCP ". If it doesn't, the client or possibly the server may be obsolete or an unrelated protocol may be used at the port.
In this document, a "newline" produced by the server or the client should be
a CR LF character sequence. It is allowed for both parties to
accept a LF character without a preceding CR character as a valid
line separator, but it is never legal to rely on this practice.
The set of session header keywords and their sequence may vary between
TTSCP implementations. Some lower case keywords are defined by this document;
in addition, any implementation may supplsr/share/df subst and
related types of rules, as well as their implementation in the
src/unit.cc file
Severity level threshold for the code area of low level speech syntheses (segments to speech). It covers both individual algorithms and the common code.
The global positive severity level threshold. Any debugging code which reaches at least this severity level is executed regardless of the code area specific threshold. This option is especially useful for generic debugging, when the code area responsible for incorrect behavior is still unknown.
The global negative severity level threshold. No debugging code
which fails to reach at least this severity level is executed regardless
of the code area specific threshold. This option is useful for setting
up a global severity level threshold for most (non-focused) code areas.
Should the always_dbg and limit_dbg options come into conflict,
the former takes precedence.
The parameter is a code area to be excepted from the limit_dbg option.
This code area will obey its own severity level limit, even if the global
negative limit is stricter. The global positive severity level is however
unaffected. Every area uses the same name as in its corresponding severity
level threshold option, without the _dbg suffix.