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: Andrei Kholodnyi
Subject: Design suggestion: The server just for synthesis
Date: Mon, 15 Nov 2010 13:38:59 +0100

> 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.

Does it mean we want to provide to the application system wide
capabilities instead of particular driver capabilities?
e.g. if a particular driver does not implement SSML we would implement
SSML for it inside provider?
and deliver "can_parse_ssml" to the application?
If yes, what about the capabilities which we can not implement e.g.
generic drivers can not generate speech samples as output?

For me it is a key design question. someone shall aggregate/handle all
these differences.
If we do not do it, then each app shall do this job.

E.g. app wants to know all voices it can get back as speech samples.
currently it will probably do:
for all drivers get capability "can_retrieve_audio"
if can_retrieve_audio
  list all voices
  add them to my favorite list

whereas we can do it for the app with High level API like:
list voices with capabilities can_retrieve_audio, i.e. hide particular
driver capabilities

This I could imagine as a high level API on top of TTS API

> 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.

the only difference in SSIP versus TTS API AFAIR are priority handling
and history. Not sure how it can be smoothly integrated.
probably it can be added on top of TTS API as well, but there are APIs
missing for it,
probably some tags can be incorporated in the messages?



reply via email to

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