Re: [orca-list] Plans for Speech Dispatcher

[Hynek Hanke <hanke brailcom org>]

On 1.7.2010 04:13, Michael Pozhidaev wrote:
> > and inside the providers themselves (between client and server, between
> > server and modules, hopefully once also between modules and TTS
> >      
> All internal communications can easily be a private concern of each
> provider. It's not so important.
>    

The form of these communications can be private, if there is a reason
for it, but even between provider and its modules, important is the 
definition
of functionality: what must be, what is important and what is less 
important.
What shall we expect from the synthesizers and what shall the provider take
care of. Where do the emulations happen. These are very important questions.
And a lot of work has already been done in this regard between the various
projects in accessibility.

And it is not that there were no results. eSpeak and 
festival-freebsoft-utils
(a higher level Festival interface) has already made use of it heavily
in their APIs, which is the two main Free Software synthesizers currently.

> > Steps have partly already been taken towards this API under the name
> > of TTS API: http://www.freebsoft.org/tts-api . Developers from
> > various sides have participated, both Gnome and KDE, and Brailcom
> > has put in our knowledge and experiences and known limitations
> > from the current SSIP protocol.
> >      
> Yes, of course, it's very useful knowledge. However it's just
> spd-specific material

Not at all.

> We have speech synthesis markup languages, ssml and jsml and they must be considered too
> (compatibility with these approaches).
>    

SSML solves a complementary task (markup for TTS translation), while
TTS API solves a broader issue of TTS management. The TTS API
specification needs such a markup language and makes use of it.
We have considered at the time of writing which of those languages
fits best our needs and we have chosen SSML with certain extensions.
I think the specification is perfectly suitable for later extension to JSML
and other markup languages. As we have proposed however, we
consider it important to advance in smaller managable steps.

> The subject now is general
> abstract D-Bus interface for all providers, since we have several of
> them.

Well, I'm not personally happy we have several. TTS API is
also a possibility to define an API that addresses the needs
for various projects and then join forces on a common
implementation that at the end really works (which is
not easy at all and we are still somehow far from there
in all the projects I know of...).

> Again, it seems to me this question must be forwarded to
> freedesktop. We see the conclusions of freedesktop are accepted by many
> projects.

Freedesktop is one of the possible grounds for cooperation
as are other means. What we need most however is that we
finalise the draft between the various projects for whom this
matters and then we can submit it to some standardization
body such as FSG. As for now, I don't think we gain anything
by moving things between places, we rather need to resume
real work on them.

Best regards,
Hynek Hanke