Created attachment 69944 [details] [review]
Adds the Speech Dispatcher backend to the list of known speech systems

Created attachment 69946 [details]
The actual Speech Dispatcher backend module

Thanks for contributing this!  I have a few questions:

1) Will you be able to implement speech progress callbacks?  These are important for things such as positioning the cursor in a text area when the user interrupts speech and highlighting text as it is spoken.

2) Can you make it so this will be more "bullet proof" in the absence of speechd?  For example, I see an "import speechd" that will obviously fail if speech dispatcher is not installed.

Thanks again.

Created attachment 70056 [details]
The actual Speech Dispatcher backend module

This is an improved version, which doesn't raise an exception if the `speechd' Python module is not installed.  The getSpeechServer() method just returns None and getSpeechServers() returns an empty list.

Comment on attachment 70056 [details]
The actual Speech Dispatcher backend module

Also a message 
"Speech Dispatcher interface not installed." is logged with the LEVEL_SEVERE priority on an attempt to instantiate the server when the `speechd' module can not be imported.  Hope that's ok with such a high priority, since it only happens when running orca setup or when starting orca after having ths backend previously selected.

Hi Tomas: thanks very much for your work in this space.  Once the drive to GNOME 2.16 has passed, we should start an overall discussion on what it means to center on SpeechDispatcher.

Comment on attachment 70056 [details]
The actual Speech Dispatcher backend module

This will need to support callbacks to allow Orca to provide visual feedback of what is being spoken and also to position the cursor when the user interrupts speech.

Comment on attachment 69944 [details] [review]
Adds the Speech Dispatcher backend to the list of known speech systems

This is dependent upon the other patch to include speech dispatcher.  I think maybe it might be nice to include both in a single patch so we can more easily track the two.

Well, do you know how to do that?  I tried passing -N to cvs diff, but it doesn't seem to include the added file in the diff.  That's why I posted the new file as a separate attachment.

Good point!  If CVS doesn't know about the file, then a cvs diff isn't going to find it.  If you do a "cvs add" on the file, it should hopefully show up.  Note that the "add" should not affect the repository until a "commit" is done, so it should be safe (as least as far as I understand the CVS docs).

cvs [server aborted]: "add" requires write access to the repository.

Thanks for checking.  Oh well...keep it separate then.  Thanks again.

Tomas:  thanks again very much for your work here!  We're very interested in getting this support into Orca, but we really need callbacks.  When will callbacks become available?

Add accessibility keyword.  Apologies for spam.

Created attachment 83532 [details]
Speech Dispatcher backend module with callback support

This version adds callback support and attempts to set the initial language according to the current locale.  Speech Dispatcher 0.6.2 is required (released on Feb 27, 2007).

Thanks Tomas!

The following string is unfortunately exposed to the user and needs to be marked for translation:

    def getFactoryName():
        return "Speech Dispatcher"
 
GNOME 2.18 is in a string freeze right now, and we recently had to pull our nautilus functionality from GNOME 2.18 regarding related issues.  I'm going to mark the target for this as Orca 2.19.0, which we will hopefully do shortly (possibly before the official GNOME 2.18 release is out).

Committed.  It took me a while to figure out what was necessary to actually get Speech Dispatcher working (I needed to run both "festival --server" and "speech-dispatcher" as root), but I eventually got at least that part working.  I also needed to build/install speech-dispatcher 0.6.2, which was a little challenging since the Python bindings didn't seem to install automatically (I had to manually run 'sudo python setup.py install' from the src/python directory).

All in all, it seems to work, with the exception of callbacks not working properly.  If you want to test this, try bringing up a document in gedit.  Press Insert+KP_Plus.  Orca should read all the lines in the file, starting wherever the caret is.  I've found it only reads the current line, which is usually an indicator that callbacks are not working.  I added a print statement to the callback method:

            def callback(type, index_mark=None):
                # This callback is called in Speech Dispatcher listener thread.
                # No subsequent Speech Dispatcher interaction is allowed here,
                # so we pass the calls to the gidle thread.
--->            print "CALLBACK", type, index_mark
                t = self._callback_type_map[type]
                if t == speechserver.SayAllContext.PROGRESS:
                    if index_mark:
                        context.currentOffset = int(index_mark)
                    else:
                        context.currentOffset = context.startOffset
                elif t == speechserver.SayAllContext.COMPLETED:
                    context.currentOffset = context.endOffset
                gobject.idle_add(orca_callback, context, t)
                if t == speechserver.SayAllContext.COMPLETED:
                    gobject.idle_add(self._say_all, iterator, orca_callback)
            self._speak(context.utterance, acss, callback=callback,
                        event_types=self._callback_type_map.keys())
  
I'm seeing the following output when I press Insert+KP_Plus and then not pressing anything:

CALLBACK begin None
CALLBACK cancel None
CALLBACK begin None
CALLBACK cancel None

I also added the following line to the _cancel method:

    def _cancel(self):
--->    print "CANCEL"
        self._client.cancel()

Since this output doesn't appear in the output above, this doesn't seem to be what is causing the cancel to be sent to the callback.

Can you take a look at this please?

Hello, you may also consider installing the following packages from Debian experimental:

  * speech-dispatcher
  * speech-dispatcher-festival
  * python-speechd

As to the problem you describe, it doesn't occur on my system.  Could you please try configuring Speech Dispatcher to use the Espeak driver?  Just uncomment the line:

AddModule "espeak-generic" "sd_generic" "espeak-generic.conf" "/var/log/speech-dispatcher/espeak.log"

in /etc/speech-dispatcher/speechd.conf and set the DefaultModule to espeak-generic.  If you have the "espeak" binary installed, espeak should be used by Speech Dispatcher after you restart it.  You may test that using the spd-say program.  This will tell us, whether the problem is in your festival setup or somewhere else.  If it persists, could you please set the LogLevel in speechd.conf to 5 and send me your log (STDERR or /var/log/speech-dispatcher/speech-dispatcher.log)?

Thank you for cooperation.

Hello, I made one more observation.  I can see the behavior you describe when I use Speech Dispatcher with Flite.  This is probably a bug in the Flite driver.  So my suspiction is that your Speech Dispatcher doesn't use Festival, but Flite, which is the default.  Can you make sure, that you have DefaultModule set to festival in /etc/speech-dispatcher/speechd.conf and that it is used (problems should be logged even with LogLevel 3)?  Also make sure you have the package festival-freebsoft-utils (available from ubuntu).  Also, instead of having to run festival manually, you may enable running festival server on startup by uncommenting the line "exit 0" at the beginning of /etc/init.d/festival.  Well, if you are fine with the espeak driver, you don't need to care about Festival at all...

> Hello, I made one more observation.  I can see the behavior you describe when I
> use Speech Dispatcher with Flite.  This is probably a bug in the Flite driver. 
> So my suspiction is that your Speech Dispatcher doesn't use Festival, but
> Flite, which is the default.  Can you make sure, that you have DefaultModule
> set to festival in /etc/speech-dispatcher/speechd.conf and that it is used
> (problems should be logged even with LogLevel 3)?

I was finally able to spend a little time with this and ended up just jumping to the espeak support.  Seems to work a lot better, and SayAll also seems to be working.  I had to modify the speechdispatcherfactory.py module a little bit (will attach a patch soon), and I also needed to muck around with the SpeechDispatcher build.  The SpeechDispatcher build seems to want to stuff the Python module under /lib and happily ignores --prefix.  As such, I needed to move the module under /usr/local by hand.

Created attachment 88169 [details] [review]
Patch to make this work with saving/restoring user preferences

Possible fix.  Tomas might have something better.

Created attachment 88170 [details] [review]
Patch from Tomas Cerha

Similar patch, just executed differently.  :-)

(In reply to comment #23)

I actually like your patch better. :-)  I guess the server id should be unique, so it should be fine to use it for lookup.  In fact, I doubt there will ever be more than one instance of the server anyway.

Committed the agreed upon patch (thanks Tomas!).  I think we should also consider closing this bug as FIXED and then open more specific SpeechDispatcher bugs as they arise.  Tomas, are you OK with that?

(In reply to comment #25)
> Tomas, are you OK with that?

Yes, definitely.  Thanks for cooperation.

Closing as FIXED.  Thanks Tomas!