Flite: a small, fast speech synthesis engine: 6. Structure

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# 6. Structure

The flite distribution consists of two distinct parts:

- The flite library containing the core synthesis code
- Voice(s) for flite. These contain three sub-parts
  - Language models: text processing, prosody models etc.
  - Lexicon and letter to sound rules
  - Unit database and voice definition

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 6.1 cst_val

This is a basic simple object which can contain ints, floats, strings and other objects. It also allows for lists using the Scheme/Lisp, car/cdr architecture (as that is the most efficient way to represent arbitrary trees and lists).

The `cst_val` structure is carefully designed to take up only 8 bytes (or 16 on a 64-bit machine). The multiple union structure that it can contain is designed so there are no conflicts. However it depends on the fact that a pointer to a `cst_val` is guaranteed to lie on a even address boundary (which is true for all architectures I know of). Thus the distinction between between cons (i.e. list) objects and atomic values can be determined by the odd/evenness of the least significant bits of the first address in a `cst_val`. In some circles this is considered hacky, in others elegant. This was done in flite to ensure that the most common structure is 8 bytes rather than 12 which saves significantly on memory.

All `cst_val`’s except those of type cons are reference counted. A few functions generate new lists of `cst_val`’s which the user should be careful about as they need to explicitly delete them (notably the lexicon lookup function that returns a list of phonemes). Everything that is added to an utterance will be deleted (and/or dereferenced) when the utterance is deleted.

Like Festival, user types can be added to the `cst_val`s. In Festival this can be done on the fly but because this requires the updating of some list when each new type is added, this wouldn’t be thread safe. Thus an explicit method of defining user types is done in ‘`src/utils/cst_val_user.c`’. This is not as neat as defining on the fly or using a registration function but it is thread safe and these user types wont changes often.

[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by Yaakov Selkowitz on May 18, 2015 using texi2html 1.82.