speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Design suggestion: The server just for synthesis


From: Tomas Cerha
Subject: Design suggestion: The server just for synthesis
Date: Mon, 15 Nov 2010 10:54:24 +0100

Dne 13.11.2010 17:11, Andrei.Kholodnyi at gmail.com napsal(a):
> i.e. what could to be done is to replace libspeechd API with TTS API,
> see http://cvs.freebsoft.org/doc/tts-api/tts-api.html#Index-of-Functions
> 
> Personally I doubt it is a good approach since it forces applications to
> deal with individual drivers and their capabilities.
> where as I expect it shall be done by the TTS Provider.
> This is what I have recently explained to Hynek during our discussion
> about system wide versus module wide voice discovery.

Hi Andrei,

Driver capabilities would be explored by the layer immediately above the driver 
layer.
It would, for example, allow proper emulatuion.  But this is still a few layers 
away
from the client API.  The client API would be a subset of TTS API, as Hynek 
pointed out.
 The client API (now libspeechd) would be extended by some new features now 
available
thanks to TTS API, but would not be the same.  The client API would still be a
transparent high level API which separates the client applications from the low 
level
details of particular TTS engines and their drivers.

An SSIP bridge can also be written on top of the new API for backwards 
compatibility.
Libspeechd, Python library and other client libraries could run without a 
change through
this brigde.

Hope this makes sense.

Tomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]