Re: [orca-list] Plans for Speech Dispatcher

[Jeremy Whiting <jpwhiting kde org>]

On Wed, Jun 30, 2010 at 4:30 AM, Hynek Hanke <hanke brailcom org> wrote:

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.

Hynek,

KTTSD switched to wrapping speech-dispatcher a year ago.  I was in discussion with you a lot at the time.  Maybe you forgot? :p  I admit it's not the best wrapper at the moment (there are some usability bugs on my end) but it works and is getting better. KTTSD (now renamed to Jovie) itself provides a dbus interface for apps to use, and has some filtering abilities, otherwise it is not much more than a wrapper around speech-dispatcher.

regards,
Jeremy

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.



_______________________________________________
Speechd mailing list
Speechd lists freebsoft org
http://lists.freebsoft.org/mailman/listinfo/speechd