Design suggestion: The server just for synthesis

[Hynek Hanke]

On 29.10.2010 19:33, Michael Pozhidaev wrote:
> I would like to discuss one suggestion. There were a lot of ideas of
> TTS calls unification and what do you think about creation an new
> separated server dedicated only to speech synthesis?

Hello Michael,

separation is good design and I totally agree with your
view. It must however be considered what is the gain and
what is the costs of such design changes.

Currently, Speech Dispatcher handles three things in the
same process:
     1) Message coordination (priorities and such)
     2) Management of TTS systems (output modules etc.)
     3) Audio output subsystem

All of the three parts are separated in a certain way already.
The audio subsystem is a separate library, TTS system management
is mostly in the modules, which are separate processes.

Of course there is such questions as where do the TTS
emulations go, how to deal with index mark callbacks
(which arise in audio subsystem, not in synthesizer)
and still maintain a good separation.

So we thought it would be good to separate these components
into entities that only communicate between themselves
over well defined protocols.

The synthesizer sends audio data + index marks positions
to the audio subsystem, the audio subsystem sends callbacks
to Dispatcher etc.

http://cvs.freebsoft.org/doc/tts-api-provider/tts-api-provider.html#General-Design

This work has already been started and I still think it is a very good way.
It is however not an easy step, it needs resources and it doesn't bring
an *immediate* advantage. On the other hand, the solution we have
today works reasonably well in what it does. In this light, Brailcom has
stopped working on the redesign. But if somebody can find one or two
full-time developers for some serious amount of time, it has all my support.

Otherwise, I would propose to proceed with smaller improvements
that will bring immediate benefit (like the good recent work being
done on the project) and wait with these bigger leaps. Brailcom is
still trying to get some more serious funding for it.

What can we do now, if we are interested -- parts of the code can
be written independently already now in Speech Dispatcher
(SSML emulation, improvements in the synthesizers, better way
of developing the output modules) and then re-used later on
in the kind of solution that you propose.

Best regards,
Hynek Hanke