[Kde-accessibility] Speech Dispatcher, KDE, dcop, and perlbox

[Gary Cramblitt]

With David's permission, I'm replying to an email he sent me so that all can 
see and participate.

On Monday 21 November 2005 09:51 am, david powell wrote:
> a question , think i already know the answer (need SD) but
> when running the machine without a x server , what would i need to do to
> get the dcop services for kttsd started ?

By definition, dcop is a KDE protocol and therefore, is only available when 
running KDE, and therefore only available when running X.  Hence, you can't 
run ktts without X.  Now there is nothing in the protocol that *requires* 
X/KDE, but that simply hasn't happened.  Similarly, the GNOME Speech API uses 
CORBA and therefore by definition, isn't available unless you're running 
GNOME and X.  Again, there is nothing in the protocol that really *requires* 
CORBA and it could be adapted to run without a desktop, but that hasn't 
happened either.  Instead, a new Interprocess Communications Protocol has 
been developed called DBUS that does not have dependencies on either desktop 
or X.

Once KDE migrates to Qt4, and Harald Fernengel's AT-SPI DBUS implementation is 
in place, it is hoped that GNOME will also migrate their ATK to DBUS and 
remove the CORBA dependencies.  Life will then be good.  KDE apps will work 
with GNOME AT tools and GNOME apps will work with KDE AT tools.  Whether 
GNOME will actually do that remains to be seen.  I am told they are waiting 
for KDE to prove the concept.

If GNOME won't migrate to DBUS, we still have the option of Harald's Qt4/ATK 
bridge, but that means that KDE users have to install about 12 GNOME 
libraries.

> i ask because i want to know even with the planned SD  would it need a
> running x server in order for the speech interface calls to be avalable
>
> the reason i ask is that i would like the effort that is going into the SD
> intigration  lead to a general common method that can be used system wide
> for apps to use a speech interface  if console or x windows is used or not

Applications interface with Speech Dispatcher via its SSIP protocol, which is 
a TCP/IP protocol.  Therefore, a SD server can be started early in the boot 
sequence after TCP/IP drivers are running.

This is one of the reasons why I'm recommending that both KDE/KTTS and GNOME 
support SD.  It is not desktop dependent and it can provide TTS services 
early in the boot sequence.  It can be used in console applications and it is 
well proven in screen-reader type applications.

> i ask as i have been having a look at perlbox , thats a speech to text and
> text to speech, it suppots kde , but does not seem to intigrate with kttsd
> and drives festival directly , the tts side has all the /dev/dsp problems
> that not using arts/alsa/gestreamer normaly gets ,just think that it would
> beinifit from beeing able to use kttsd in kde , but thay try and suport
> other xwindows managers , and there is a console mode for non x ,
> with speech to text in some ways beeing another accessibility reqiuirement
> for some  there are some forms of disability that it would be a very usefull 
addition

We need yet another TTS system like we need a hole in our heads.

As for audio.  Frankly the situation is a mess.  As Hynek Hanke recently put 
it, NONE of the existing audio frameworks is really suitable for 
accessibility TTS.  ALSA suffers from poor documentation and mixing problems.  
aRts has its problems and of course is dependent on KDE.  GStreamer has high 
latency (and to make matters worse, the latest releases are ABI incompatible 
with earlier releases).  NAS and NMM also have problems.  Hynek could 
probably give a more detailed and accurate list of the problems than I.

The freestandards.org Accessibility Group drafted a set of accessibility audio 
requirements and Olaf presented it at aKademy 2005.  Unfortunately, I think 
like 2 people attended the talk, so the requirements haven't received wide 
recognition.  Most of the multimedia framework guys are concentrating on 
playing music and videos and aren't really thinking much about our needs.  I 
don't think the situation will improve anytime soon.

<insert multimedia framework flame wars here>

My personal opinion is that ALSA is our best hope.  Most of the other 
multimedia frameworks work with ALSA, the ALSA guys claim that the dmix 
problems are finally solved in the latest versions, and if someone could 
clean up the documentation problem..

But actually, I'm just tired of struggling with audio issues.  I want to 
expend my energy solving accessibility problems; not solving multimedia 
framework problems.

-- 
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
http://accessibility.kde.org/developer/kttsd/index.php