speechd-up status and ideas

[Bill Cox]

On Tue, Jan 18, 2011 at 11:48 PM, William Hubbs <w.d.hubbs at 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