speechd-up status and ideas

speechd-up status and ideas

[William Hubbs]

All,

My speechd-up home page on github is http://www.github.com/williamh/speechd-up.

You can clone the repository by doing:

git clone git://github.com/williamh/speechd-up.git

This repository contains all of the changes from ospeakup, and I am
planning to move forward from there.

My plan for speechd-up is to give it a -u option so that you can tell it
to switch to a different user before it tries to connect to
speech-dispatcher, that way we can use the autospawn feature and not
have speech-dispatcher or speechd-up running system wide.

What does everyone else think of that option?

William

Re: speechd-up status and ideas

[Bill Cox]

I like that option.  However, at least currently in Vinux,
speech-dispatcher crashes pretty often, every few hours I find on my
setup.  So, while it's pretty gross, we'll probably keep both the
system wide speech-dispatcher for ospeakup, and a user specific
speech-dispatcher for Orca, until the remaining stability issues get
ironed out.

Bill

> All,
>
> My speechd-up home page on github is http://www.github.com/williamh/speechd-up.
>
> You can clone the repository by doing:
>
> git clone git://github.com/williamh/speechd-up.git
>
> This repository contains all of the changes from ospeakup, and I am
> planning to move forward from there.
>
> My plan for speechd-up is to give it a -u option so that you can tell it
> to switch to a different user before it tries to connect to
> speech-dispatcher, that way we can use the autospawn feature and not
> have speech-dispatcher or speechd-up running system wide.
>
> What does everyone else think of that option?
>
> William
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: speechd-up status and ideas

[Steve Holmes]

I like the idea of having it work in either user or system wide mode.  I 
will have to give this new setup a try.  I have Orca working with speech 
dispatcher as a system wide process in Arch Linux and it's great.  I 
think the system is faster slightly if I can keep speechd running as a 
single process and let the other a11y packages just call into it.

On 01/18/2011 02:28 PM, Bill Cox wrote:
> I like that option.  However, at least currently in Vinux,
> speech-dispatcher crashes pretty often, every few hours I find on my
> setup.  So, while it's pretty gross, we'll probably keep both the
> system wide speech-dispatcher for ospeakup, and a user specific
> speech-dispatcher for Orca, until the remaining stability issues get
> ironed out.
>
> Bill
>
>

Re: speechd-up status and ideas

[William Hubbs]

Hi Steve,

On Tue, Jan 18, 2011 at 08:09:21PM -0700, Steve Holmes wrote:
> I like the idea of having it work in either user or system wide mode.  I 
> will have to give this new setup a try.  I have Orca working with speech 
> dispatcher as a system wide process in Arch Linux and it's great.  I 
> think the system is faster slightly if I can keep speechd running as a 
> single process and let the other a11y packages just call into it.
 
 I don't have the user mode set up yet, but feel free to clone my git
 repository for speechd-up and see where we are on it.

 Once I get the user mode set up, I will do a release.

If I can make things work with speechd-up the way I want them to, you
won't need to run sd in system wide mode. What I want to work toward is
having sd drop privs to the user you give it with the -u option, open
the /dev/softsynth device, then connect to sd, which will autospawn a
copy of sd running as that user.

 William

Re: speechd-up status and ideas

[Bill Cox]

On Tue, Jan 18, 2011 at 11:48 PM, William Hubbs <w.d.hubbs@gmail.com> wrote:
> If I can make things work with speechd-up the way I want them to, you
> won't need to run sd in system wide mode. What I want to work toward is
> having sd drop privs to the user you give it with the -u option, open
> the /dev/softsynth device, then connect to sd, which will autospawn a
> copy of sd running as that user.

I support this, but I'm just curios about implementation details.

Will this work on the consoles before a user has logged in?  What if
I'm logged into my gnome desktop with Orca running, which spawns
speech-dispatcher, switch to a console and login, and then log out on
my gnome desktop?  Currently, /dev/softsynth only allows read/write by
root.  Will making it world writable cause any security issues?

I think it is possible to get all this right, but it would be easy to
get it wrong.  The approved way would add a lot of complexity and
potential instability: deal with session management, create a session
for non-logged-in users on consoles, and such (which may have already
happened).  Attach to d-bus for session information, and SD is
considering moving to d-bus anyway.

However, speechd-up is currently a very simple single source file
project.  Even so, it was very buggy up until the ospeakup upgrades.
Before then, no one used speechd-up because it sucked.  I'd hate to
see it get very complicated.

I believe speech-dispatcher is already there, much to the detriment of
the project.  Note, for example, the continuing instability issues.
Note that important SD features like returning sound samples to the
application are so hard to implement, they never will be.  Voiceman,
an alternative to SD, only exists because SD will likely never support
auto-detection of language.  Integration of new TTS engines into SD
requires typically 1,000 lines of multi-threaded C code.  Integration
should be super easy, but the process isn't even well documented.  You
can't even attach to SD TTS clients with a debugger, and have to
develop with printf, as if we were writing kernel drivers.  Important
real functionality, like dealing with punctuation consistently, aren't
dealt with in SD.  Bugs like saying capital all the time rather than
increasing the pitch, continue for years.

Anyway, I'd just be careful to remember the KISS rule (keep it simple,
stupid), and try not to make things more complicated than need be.  If
SD had done this, we'd have one universal speech switch running on
everything from Android to Windows.  TTS engines could be integrated
once, and run everywhere.  We'd have one speech back end, rather than
SD, Voiceman, and the emacspeak speech server (among others).  As it
is, it's hard as hell to even get speakup talking to SD reliably, with
just one copy running.  It's no wonder that most people just use
espeakup.  Yasr support in Vinux broke recently because of changes in
SD.  What's left is SD being used to connect Orca to espeak, and even
that crashes every now and then.  And so... what's considered a high
priority for SD?  I hope to God it's not freaking d-bus integration.

I honestly think about throwing away SD and starting over with a clone
that could act as a drop-in replacement.  Then, all that other cool
stuff could happen.

Bill

Re: speechd-up status and ideas

[Steve Holmes]

On Wed, Jan 19, 2011 at 07:02:53AM -0500, Bill Cox wrote:
> I honestly think about throwing away SD and starting over with a clone
> that could act as a drop-in replacement.  Then, all that other cool
> stuff could happen.

Hum, that sounds like another fork; we already merged the last fork
(along with its improvements and bug fixes) into SD.  I've been out of
the SD loop lately; we're not headed into another convoluted mess, are
we?  That whole thing called TTS API has never gotten off the ground
from what I've seen or should I say, not seen.

> Bill
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup