[orca-list] Plans for Speech Dispatcher

[Hynek Hanke]

On 30.6.2010 03:57, Michael Pozhidaev wrote:
>> 2) After the release of 0.7.1, we plan to start working on
>> two major improvements for the 0.8 release: DBUS interface
>> and closer session integration using such technologies
>>      
> Will D-Bus interface be respondable only for control operations
> (stop server, etc) or there will be D-Bus interface to sent speech
> commands?

It will be used in both cases.

> It seems to me the second  may be amazing idea. It can be the
> simplest way to produce speech output from any place you want. But one
> important thing: if spd will  process commands to say any text and stop
> output with D-Bus it would be great to initiate public discussion to get
> some common interfaces for TTS engines accessible with D-BUS. Every TTS
> provider (kttsd, for example) may be interested in such interfaces
> research. Apparently, using common interfaces increases
> interchangebility between TTS engines

Yes, this is a good note, although a little imprecise. Neither
Speech Dispatcher nor OpenTTS or KTTSD are TTS engines,
they are just high level interfaces to them. KTTSD actually has plans
to make Speech Dispatcher it's default interface and drop it's
own engines or port them to Speech Dispatcher. Only problem
is there is noone to implement it.

I agree it would be good to have a common DBUS API, both between
the different providers (Speech Dispatcher, OpenTTS and KTTSD)
and inside the providers themselves (between client and server, between
server and modules, hopefully once also between modules and TTS
engines themselves). Whether the various sides will join the effort
we can't forsee, but we can hope.

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.

TTS API partly overlaps with SSIP (current Speech Dispatcher
protocol), but defines just the part important to TTS, not the part
important to message dispatching (clients management, priorities etc),
which is yet to be defined.

The new DBUS API should be based on TTS API, so that it respects
the conclusions reached so far with regards to management of the
TTS engines and allow extensibility to eventually cover the full range
of TTS API functionality. It will in the first instance however only
implement the functionality covered by the existing SSIP protocol
and already implemented in Speech Dispatcher.

We also have a partly completed fuller implementation of TTS API
under the name of TTS API Provider, but we will not switch to it now
as considerable work still remains to be done and the new
implementation must be well tested first. Also, several things
have changed since we have last been working on it, so that
must be reworked.
   http://cvs.freebsoft.org/doc/tts-api-provider/tts-api-provider.html

I think it is important that we advanced in smaller well-defined
and manageable steps, but in such a way that all this work can
be put together eventually.

Best regards,
Hynek Hanke
Brailcom, o.p.s.