Design suggestion: The server just for synthesis

[Michael Pozhidaev]

Hello, Hynek!

Let see what advantages we can get with this work:

1. First of all - stability. Multi-threaded application were always very
difficult to debug and maintain. Having two independent servers for
different purposes we can reduce undesired influence and increase
isolation between parts.

2. Simplification of configuration tasks. Audio output configuration and
TTS configuration is generally independent things. We can increace
transparency of configuration data.

3. Using remote TTS engines in LAN. I suppose, this is obvious
effect. 

4. Extending TTS server using. Accessibility is not the single
application of TTS. There are a lot of other tasks which need TTS
functions.

I can really take this work and try to do it keeping complete approval
of speechd community. Of course, the result will not be immediate, but 
I am convinced it is the real way to merge our effort to create good
speech output structure. I am not able to dedicate full time to this
work, but it seems to me everything is possible.

Do you agree to include support of remote TTS server we are discussing into
speechd when some versions be ready?

I am completely agree using of pure C has clear advantages but want to
 ask: do you have strong reasons to reject using C++? 

> 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
>
>
>
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd

-- 
Michael Pozhidaev. Tomsk, Russia. E-mail: msp at altlinux.ru
Russian info page: http://www.marigostra.ru/