running speech-dispatcher-0.7.1 in system mode

[Trevor Saunders]

Hi,

On Tue, Oct 05, 2010 at 01:07:31PM +0200, Hynek Hanke wrote:
> On 4.10.2010 15:32, Christopher Brannon wrote:
> >But the point is that it isn't really easy to run it as a
> >system-wide service anymore.

I think all we need to do however is bring over the option, and may be
another command line option or two from opentts to make this work
correctly.

> The problem is it never was. Distribution used to put
> an exit 0 at the start of the init script due problems with
> audio. Either of these used to be the first crash and
> burn for the user.

what?  I don't really care, and have never looked into ubuntu's issues
with pulse so I won't speak to there issues, but it would be nice if
people stopped only caring about the problems pulse, there are other
audio output methods that work just fine in system mode.  System mode
has always worked very well in debian for me, First with an init script,
and now that I don't generally install the package a start in rc.local.
In any case I'm willing to accept that a system mode with pulse may be
problematic however that is _very_different_ from a general doesn't work
well.

> Further, if the user was to get it working with Pulse
> Audio, then he had to setup manually a configuration
> in his home directory and choose a correct port. The
> offered value of 6561 was often not the correct value.
> And then of course one needed to set SPEECHD_PORT
> correctly. All on command line, just to get something
> working.

that sounds like a packaging problem, but I don't have any experience
with making it work with pulse.  In any case, I have no issues with a
working session mode setup for people who need pulse or whatever.

> And then you get all the problems with order of
> startup. Clients before Speech Dispatcher, Speech
> Dispatcher before audio subsystem...

what?  this _is_ why init scripts specify dependancies so they are
started first this way audio is started before speech-dispatcher which
is started before the clients so they can all just assume there
dependancies are there.

> These days, the user installs Speech Dispatcher from
> a package, starts Orca or speechd-el and Speech Dispatcher
> is autostarted and starts talking.

I have to disagree, I think its harder to get everything working now.
It used to be that you installed the package, the init script was used
to start the deamon, and everyone could just rely on the fact the system
was providing a speech dispatcher at a known address.   While I haven't
installed the package in a while (I probably should test it), from
reading debian-accessibility it doesn't look like this is the case any
more.   Installing from git I have seen cases where I've just run orca
forgeting I have to do stuff to make orca use the global seech
dispatcher, and as a result instead of a second speech dispatcher being
autospawned I get nothing.  I also strongly suspect there is atleast one
race in the autospawn code.

imho a system service started by an init script is just a cleaner
solution, the system declares that the service while be available at a
known address like any other daemon, and then clients can rely on that
when creating connections.  On the other hand with autospawn the library
has to have code to handle the case it needs to start the server.

> I think distributions should really consider whether to
> ship the system mode and if they are even able to
> resolve all the complicated relations it actually has.

I think it has far less issues than autospawn, except perhaps in the case
of people using pulse.
 
> And of course we have these clients which needs to
> be improved to be able to work in this automatic way.

 There are some clients like brltty which as Samuel has already
 explained to you _can't_ work this way.  Even if they could, and it was
 a good idea it takes time to do this.  Finally the ssip /
 speech-dispatcher documentation for a long time publisized that speech
 dispatcher would speak a public protocol on at a known address, so you
 can hardly stop doing tht one day and expect everyone else to
 immediately change.

> I think we are often lacking a comparison with
> the zero state. What kind of problems would we have
> today, if we didn't do anything...

from here not much, there's the alsa issues, and if you care about it
pulse, but otherwise everything that was wrong with 0.67 was internal
stuff like segfaults, and other random bugs.

Trev

> 
> Best regards,
> Hynek
> 
> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20101005/84e85b95/attachment-0001.pgp>