When I try to install speechd-up package I get this error:

E: speechd-up: subprocess installed post-installation script returned error
exit status 1

Synaptic marks the package as installed. If I try to reinstall the package I
get this error:

E: Internal Erro                        r, No file name for speechd-up:amd64

Hello,

Mika Hanhijärvi, on dim. 09 avril 2017 13:42:36 +0300, wrote:

Do you happen to have the espeakup package installed too?  They can't
work at the same time.

Otherwise, could somebody from debian-accessibility check whether
speechd-up works with the current speech-dispatcher?

Samuel

Hello



No. I do not have espeakup installed.

I removed espeakup because I wanted to try if speechd-up would solve
atleast part of the one problem I have (maybe offtopic here). For some
reason if espeakup speaks something when computer is booting then screen
reader does not speak on Gdm login screen and on desktop. But espeak
speaks on console.  So I have to reboot sometimes severaltimes. If
espeakup does not say anything when computer boots, then screen reader
speaks on gdm, but not on console. If I then login to desktop then  Orca
speaks on desktop, but  if I go back to gdm screen whitout logging out
from desktop first then screen reader does not speak on gdm screen.
espeakup also does not speak on console. If I logout from desktop then
screen reader starts to speak on gdm screen again, but espeak still does
not speak on console. So I can not switch between desktop, gdm login
screen and console, I am blind so I need to use screen reader.

I have no idea to which package I would need to file the bug, because I
do not know if the problem is in espeakup, pulseaudio,
speech-dispatcher, Orca or espeak / espeak-ng   ...

So I wanted to try if speechd-up would solve atleast part of the problem.

- Mika

Hi,

I did some tests and installing speechd-up failed the same way.

install log from aptitude:

Selecting previously unselected package libdotconf0:amd64.
(Reading database ... 295864 files and directories currently installed.)
Preparing to unpack .../libdotconf0_1.3-0.2_amd64.deb ...
Unpacking libdotconf0:amd64 (1.3-0.2) ...
Selecting previously unselected package libspeechd2:amd64.
Preparing to unpack .../libspeechd2_0.8.6-4_amd64.deb ...
Unpacking libspeechd2:amd64 (0.8.6-4) ...
Selecting previously unselected package speech-dispatcher-audio-plugins:amd64.
Preparing to unpack .../speech-dispatcher-audio-plugins_0.8.6-4_amd64.deb ...
Unpacking speech-dispatcher-audio-plugins:amd64 (0.8.6-4) ...
Selecting previously unselected package speech-dispatcher.
Preparing to unpack .../speech-dispatcher_0.8.6-4_amd64.deb ...
Unpacking speech-dispatcher (0.8.6-4) ...
Selecting previously unselected package speechd-up.
Preparing to unpack .../speechd-up_0.5~20110719-6+b1_amd64.deb ...
Unpacking speechd-up (0.5~20110719-6+b1) ...
Processing triggers for install-info (6.3.0.dfsg.1-1+b2) ...
Setting up libspeechd2:amd64 (0.8.6-4) ...
Processing triggers for libc-bin (2.24-9) ...
Setting up libdotconf0:amd64 (1.3-0.2) ...
Processing triggers for systemd (232-22) ...
Setting up speech-dispatcher-audio-plugins:amd64 (0.8.6-4) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up speech-dispatcher (0.8.6-4) ...
Setting up speechd-up (0.5~20110719-6+b1) ...
Job for speechd-up.service failed because the control process exited with error code.
See "systemctl status speechd-up.service" and "journalctl -xe" for details.
invoke-rc.d: initscript speechd-up, action "start" failed.
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
   Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2017-04-16 10:45:25 CEST; 12ms ago
     Docs: man:systemd-sysv-generator(8)
  Process: 31268 ExecStart=/etc/init.d/speechd-up start (code=exited, status=1/FAILURE)

Apr 16 10:45:23 deb9 speechd-up[31268]: Starting Interface between speakup and speech-dispatcher : speechd-up[Sun Apr 16 10:45:23 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Apr 16 10:45:23 deb9 speechd-up[31268]: Starting speechd-up...
Apr 16 10:45:23 deb9 speechd-up[31268]: To work, speechd-up needs speakup and speakup_soft modules.
Apr 16 10:45:23 deb9 speechd-up[31268]: They are loaded automatically. If you don't want, type
Apr 16 10:45:23 deb9 speechd-up[31268]: rmmod speakup speakup_soft
Apr 16 10:45:25 deb9 speechd-up[31268]:  failed!
Apr 16 10:45:25 deb9 systemd[1]: speechd-up.service: Control process exited, code=exited status=1
Apr 16 10:45:25 deb9 systemd[1]: Failed to start LSB: Interface between speakup and speech-dispatcher.
Apr 16 10:45:25 deb9 systemd[1]: speechd-up.service: Unit entered failed state.
Apr 16 10:45:25 deb9 systemd[1]: speechd-up.service: Failed with result 'exit-code'.
dpkg: error processing package speechd-up (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (232-22) ...
Errors were encountered while processing:
 speechd-up
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up speechd-up (0.5~20110719-6+b1) ...
Job for speechd-up.service failed because the control process exited with error code.
See "systemctl status speechd-up.service" and "journalctl -xe" for details.
invoke-rc.d: initscript speechd-up, action "start" failed.
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
   Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2017-04-16 10:45:29 CEST; 13ms ago
     Docs: man:systemd-sysv-generator(8)
  Process: 31560 ExecStart=/etc/init.d/speechd-up start (code=exited, status=1/FAILURE)

Apr 16 10:45:27 deb9 speechd-up[31560]: Starting Interface between speakup and speech-dispatcher : speechd-up[Sun Apr 16 10:45:27 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Apr 16 10:45:27 deb9 speechd-up[31560]: Starting speechd-up...
Apr 16 10:45:27 deb9 speechd-up[31560]: To work, speechd-up needs speakup and speakup_soft modules.
Apr 16 10:45:27 deb9 speechd-up[31560]: They are loaded automatically. If you don't want, type
Apr 16 10:45:27 deb9 speechd-up[31560]: rmmod speakup speakup_soft
Apr 16 10:45:29 deb9 speechd-up[31560]:  failed!
Apr 16 10:45:29 deb9 systemd[1]: speechd-up.service: Control process exited, code=exited status=1
Apr 16 10:45:29 deb9 systemd[1]: Failed to start LSB: Interface between speakup and speech-dispatcher.
Apr 16 10:45:29 deb9 systemd[1]: speechd-up.service: Unit entered failed state.
Apr 16 10:45:29 deb9 systemd[1]: speechd-up.service: Failed with result 'exit-code'.
dpkg: error processing package speechd-up (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 speechd-up

Manually starting speechd-up.service fails the same way.
/var/log/speechd-up.log, with LogLevel 5:

[Sun Apr 16 11:13:42 2017] speechd: Speechd-speakup starts!
[Sun Apr 16 11:13:42 2017] speechd: ERROR! Can't connect to Speech Dispatcher!

speech-dispatcher.service seems to be okay.

$ systemctl status speech-dispatcher.service
● speech-dispatcher.service - LSB: Speech Dispatcher
   Loaded: loaded (/etc/init.d/speech-dispatcher; generated; vendor preset: enabled)
   Active: active (exited) since Sun 2017-04-16 10:45:22 CEST; 34min ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/speech-dispatcher.service

If someone has any ideas for debugging this, I'd be happy to help out.

Hi all,

Same for me.

I added some debugging info to /etc/init.d/speechd-up, and it turns out
that the error is generated because the /proc/$pid in running_pid()
doesn't exist. It should exist as the call to start_daemon() in
start_server() was successful. When I run the command that I think is
executed there manually, the daemon starts properly and the dir in /proc
exists:

paul@testavoira ~ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
--quiet --oknodo --chdir "$PWD" --exec /usr/bin/speechd-up --oknodo
--pidfile /var/run/speechd-up.pid -- -l1
[Sun Apr 16 21:49:40 2017] speechd: Configuration has been read from
"/etc/speechd-up.conf"
paul@testavoira ~ $ ll -d /proc/$(cat /var/run/speechd-up.pid)
dr-xr-xr-x 9 root root 0 apr 16 21:49 /proc/6276

I haven't figured out the difference yet.

Paul

Hi

Probably somebody who knows systemd should have a look. I have the
feeling it is interfering with the script and not doing what I read.

I have no clue where to find the input (the service file?) that systemd
is actually using yet. This is all new to me.

Paul

Hi,

We're going to have a look, but here I cannot reproduce. On Stretch, I
install the package without problems. So I am surprised. I may have
systemd-sysv, indeed, but not much more.

Regards,


Le 16/04/2017 à 22:17, Paul Gevers a écrit :

Hi,

that's where I stopped yesterday. Manual start works, using systemd or
the init.d script (which systemd calls) does not.
I added set -x to /etc/init.d/speechd-up and checked what I could, but
couldn't find what went wrong. start-stop-daemon succeeded, but the
process still died and the log contained that ERROR line.
Running the exact same start-stop-daemon command works for me as well.

I just tried again and the funny thing is, *restarting* speechd-up with
systemd works totally fine as long as I start speechd-up manually with
start-stop-daemon.

$ sudo /sbin/start-stop-daemon --start --nicelevel 0 --quiet --oknodo --chdir / --exec /usr/bin/speechd-up --oknodo --pidfile /var/run/speechd-up.pid -- -l1
$ sudo systemctl restart speechd-up.service
$ systemctl status speechd-up.service
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
   Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
   Active: active (running) since Mon 2017-04-17 11:48:36 CEST; 1s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 10728 ExecStop=/etc/init.d/speechd-up stop (code=exited, status=0/SUCCESS)
  Process: 10760 ExecStart=/etc/init.d/speechd-up start (code=exited, status=0/SUCCESS)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/speechd-up.service
           └─10778 /usr/bin/speechd-up -l1

I can restart as often as I want, it works each time.
The shell trace looks exactly the same for both systemd restart and
start (except for times and PIDs of course) up to the point where the
init script sleeps 2 seconds before checking whether speechd-up is
still running. In the restart case there are these two lines in the
journal, right after "sleep 2" and before calling "running":
kernel:  updated 224 of 224 character descriptions
kernel:  updated 96 of 180 character class entries
While running systemctl start, these two lines are missing.

Hi,

That's weird. I just tried the installation on a vbox snapshot of
stretch, which failed as well. That image was created with the RC2
installer and updated just now. Pretty standard setup with:
task-desktop
task-laptop
task-xfce-desktop
virtualbox guest additions installed via (virtual) CD

Right now, I have 1348 packages installed. I'm attaching the output of
dpkg --list in case this could help narrowing down any differences.

Hi Jean-Philippe,

Seems like your system is the only system where it works then. Also in
Ubuntu, this issue was twice reported¹, while looking at the popcon, it
isn't heavily installed. That makes 5 people where it fails to install.

Paul

¹ https://bugs.launchpad.net/ubuntu/+source/speechd-up/+bug/1504054

topic of theirs so I'm "playing along" to finally learn a little more
about it.

I was able to install speechd-up successfully, BUT I have no idea if
it's functional because I don't know how to use it.

I'm on a super basic debootstrap'ed Stretch with Xfce4 as my primary
desktop environment. I've got Fluxbox and something else small that
I've forgotten because I haven't switched around between them in a
while.

All of this is being provided in case it somehow helps explain why
it's working for some of us and not for others.

About the only programs I have are: Libreoffice, GIMP, Inkscape,
Openshot, newly installed Piviti, Xine, and PySolFC (card games).

For sound, aumix is my hero because I went almost a year without sound
until I discovered that package. Others installed include GNOME ALSA
mixer, Qas mixer, mpv video player. Seriously, I was desperate and
downloading things that even remotely sounded like they might help
trigger sound back on.

Again, am mentioning all those because maybe they did something that
triggered at least a successful install. Whether it actually works as
intended or not, I have no clue aka literally clueless.

As for systemd, I haven't touched a thing there. My system is whatever
comes with a debootstrap install.

I'm on a now older ASUS 10" where "uname -a" gets: Linux northpole
4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux

That's all I can think to write right now. :)


#ThankYou for the work you all do!

Cindy :)

Hi all,

I don't know what to make of it, but when I first start the speechd-up
daemon by hand, then the init script succeeds (because it finds the
daemon already running). But now it comes, I then can stop and start the
daemon successfully, but only when I am quick enough. This is
reproducible, sleep 4 works always, sleep 5 always fails (so far).

paul@testavoira ~/ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
--quiet --oknodo --chdir "/" --exec "/usr/bin/speechd-up" --oknodo
--pidfile "/var/run/speechd-up.pid" -- -l1
[Tue Apr 18 21:46:42 2017] speechd: Configuration has been read from
"/etc/speechd-up.conf"

paul@testavoira ~ $ sudo service speechd-up start

paul@testavoira ~ $ sudo service speechd-up stop ; sleep 4 ; sudo
service speechd-up start

paul@testavoira ~ $ sudo service speechd-up stop ; sleep 5 ; sudo
service speechd-up start
Job for speechd-up.service failed because the control process exited
with error code.
See "systemctl status speechd-up.service" and "journalctl -xe" for details.

If I look at the processes that are running after a sleep 4 look, I
notice that speech-dispatcher keeps the same PID, so apparently with
sleep 4 it isn't killed and still alive when speechd-up wants to connect
to it. With sleep 4, the speech-dispatcher is killed and speechd-up
fails to connect (as seen in the speechd-up.log).

The big question is why systemd can't get speech-dispatcher up before
speechd-up wants to talk to it. One thing I noticed is that
/etc/default/speech-dispatcher has RUN=no, so starting speech-dispatcher
with the init script succeeds, but doesn't do anything. I think that
that may cause the confusion of systemd as the speechd-up init script
depends on the speech-dispatcher init script.

Setting RUN=yes, allows systemd to start speech-dispatcher, but
apparently that isn't enough, because it still fails to start
speechd-up. Speech-dispatcher isn't running anymore after starting
speechd-up while it was running before calling the init script, so it
looks like systemd tries to restart speech-dispatcher and fails doing
that properly.

Paul

Hi,
manually starting speechd-up. The timing influence is interesting.
start-stop-daemon works. That doesn't take care of any dependencies.

Anyway, I fired up my vm again and switched init systems.
Using systemd-sysv, the installation and daemon start fail.
Using sysvinit-core, the installation completes without any error, but
restarting or starting speechd-up fail:

Selecting previously unselected package speechd-up.
(Reading database ... 113373 files and directories currently installed.)
Preparing to unpack .../speechd-up_0.5~20110719-6+b1_amd64.deb ...
Unpacking speechd-up (0.5~20110719-6+b1) ...
Setting up speechd-up (0.5~20110719-6+b1) ...
[....] Starting Interface between speakup and speech-dispatcher : speechd-up[Wed Apr 19 19:59:28 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Starting speechd-up...
To work, speechd-up needs speakup and speakup_soft modules.
They are loaded automatically. If you don't want, type
rmmod speakup speakup_soft
. ok
Processing triggers for systemd (232-22) ...

$ sudo service speechd-up restart
[....] Restarting Interface between speakup and speech-dispatcher: speechd-upStopping speechd-up and unloading speakup modules...
[Wed Apr 19 20:00:07 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Starting speechd-up...
To work, speechd-up needs speakup and speakup_soft modules.
They are loaded automatically. If you don't want, type
rmmod speakup speakup_soft
 failed!

$ sudo service speechd-up status
[FAIL] Checking status of Interface between speakup and speech-dispatcher: speechd-up apparently not running failed!

$ sudo service speechd-up start
[....] Starting Interface between speakup and speech-dispatcher : speechd-up[Wed Apr 19 20:00:52 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Starting speechd-up...
To work, speechd-up needs speakup and speakup_soft modules.
They are loaded automatically. If you don't want, type
rmmod speakup speakup_soft
 failed!

Rebooting the machine doesn't change anything, it still fails.

So the installation works, but the package is still unusable.

I rebooted each time after changing the init system before trying to
install speechd-up. Installing everything below except sysvinit-core
doesn't help when running systemd.
Diffing the package lists, for the record:
38a39
215a217,218
335a339
663a668,669
1196a1203
1204c1211,1213
< ii  systemd-sysv                          232-22                            amd64        system and service manager - SysV links
---

Out of curiosity, I then removed systemd completely and kept only
libsystemd0. Speechd-up still fails the same way, so I don't think
systemd can be blamed here.
Manually starting speechd-up with start-stop-daemon still works, but
service restart and stop/restart still fail.
I also noticed that there's a sleep 10 when restarting with service
between the stop and start. Reducing DIETIME to 2 lets me restart
speechd-up via service after launching it with start-stop-daemon,
matching Paul's observations. Doesn't help with start, though.

Now I'm really wondering how people manage to run speechd-up
successfully.

Some things have been snipped above while I hope I left enough of
Paul's latest feedback to give it due Respect. :)

Simultaneous in my inbox is a different bug about Synaptic possibly
keeping Orca from operating while Synaptic is open. It's this Bug
#859262.

Synaptic "freezes Orca screen reader"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859262

Is something like that maybe a possibility?

Seeing the word "Synaptic" also originally made me wonder if our
*_CHOICE_* of package managers is affecting things somehow.

In my case, I have neither Synaptic nor Orca open because I don't use
those. I only use "apt-get" via terminal interface for my package
management.

One thing is that I still don't know how to actually test speechd-up's
functionality. For now, all I know is that it appeared to have
successfully, initially installed with no complaints (via "apt-get
install speechd-up").

Another factor in my install attempt is that mine was a brand new
install. There was no residual "clutter" of past installs that could
potentially also be causing unknown complications.

Cindy :)

Hi,

1st, I have always had the idea the the spd service had bugs and was not
really usable: spent so resource, didn't run really, etc. Hence the fact
it's always been in "no" in defaults/speech-dispatcher.

2nd, given this feedback, maybe we may try requesting to the initscript
to wait for some seconds, with a kind of pause parameter? Would it fix
the bug?

Regards,


Le 19/04/2017 à 22:18, Cindy-Sue Causey a écrit :

Hi Jean-Philippe,

So, does that mean that speechd-up should also have such a mechanism
that defaults to no?

What I am now seeing is that speech-dispatcher doesn't stay running when
started with it's init script. If I start it with "sudo service
speech-dispatcher start" than it is in the "active (running)" state for
about 20 seconds and then goes to an "active (exited)" state. I expect
that speechd-up is failing to start because it actually checks if it can
USE speech-dispatcher.

Two things that I then noticed, the man page of speech-dispatcher
mentions that it needs to be started with the "-d" option to run as
daemon (which isn't present in its init file). With debugging
information added I then noticed the following in
/tmp/speechd-debug/speech-dispatcher.log:
[Fri Apr 21 14:10:00 2017 : 638612] speechd: Currently no clients
connected, enabling shutdown timer.
[Fri Apr 21 14:10:05 2017 : 713820] speechd: Terminating...

So it seems speech-dispatcher doesn't want to stay running as daemon. I
guess this is the real issue at stake. (Should we reassign?)

Just to be sure, you mean pausing in the speech-dispatcher init script,
right? Speechd-up already has that. Because of the above, this doesn't
help. I even tried it (actually before I found out the above) and it
didn't work.

Paul

Hi,
"speech-dispatcher is usually started automatically by client libraries
(i.e. autospawn), so you only need to run it manually if
testing/debugging, or when in other explicit need for a special setup."

So this behaviour doesn't seem broken to me, that's rather exactly as
expected. Also, starting speechd-up with start-stop-daemon doesn't show
any failures, despite missing special handling of speech-dispatcher.
There is an open bug about autospawn with multiple users in #616313,
but I don't see an immediate connection to our issues; we're always
root and not touching speechd-up directly.

I enabled this line in /etc/speech-dispatcher/speechd.conf:
CustomLogFile "protocol" "/var/log/speech-dispatcher/speech-dispatcher-protocol.log"

/var/log/speech-dispatcher/speech-dispatcher-protocol.log stays empty
when using service (my VM is still using sysvinit-core now), but when I
use the usual start-stop-daemon command, I get this log:

[Thu Apr 20 15:31:30 2017 : 10113] speechd:     22:DATA:|SET SELF CLIENT_NAME "test:speakup:softsynth"
| (47)
[Thu Apr 20 15:31:30 2017 : 10730] speechd:     22:REPLY:|208 OK CLIENT NAME SET
|
[Thu Apr 20 15:31:30 2017 : 11457] speechd:     22:DATA:|SET SELF NOTIFICATION index_marks on
| (38)
[Thu Apr 20 15:31:30 2017 : 11490] speechd:     22:REPLY:|220 OK NOTIFICATION SET
|
[Thu Apr 20 15:31:30 2017 : 11860] speechd:     22:DATA:|SET SELF NOTIFICATION all on
| (30)
[Thu Apr 20 15:31:30 2017 : 11890] speechd:     22:REPLY:|220 OK NOTIFICATION SET
|
[Thu Apr 20 15:31:30 2017 : 12102] speechd:     22:DATA:|SET SELF CAP_LET_RECOGN none
| (30)
[Thu Apr 20 15:31:30 2017 : 12131] speechd:     22:REPLY:|206 OK CAP LET RECOGNITION SET
|
[Thu Apr 20 15:31:30 2017 : 12356] speechd:     22:DATA:|SET SELF SSML_MODE on
| (23)
[Thu Apr 20 15:31:30 2017 : 12380] speechd:     22:REPLY:|219 OK SSML MODE SET
|

To me, this confirms that autospawn is working, but not when speechd-up
is started by any init system despite having the exact same command
line. I didn't bother switching to systemd again for now.
I also dumped the env from bash and the initd script, but couldn't see
any suspicous differences.

If only speechd-up could provide some detailed logs, but it isn't
particularly chatty when starting up, despite LogLevel 5.

Also, I can confirm hearing some speech at one point when manually
starting speechd-up with start-stop-daemon, but the volume was too low
to understand what it was and it didn't happen again.

Hi

Hmm, should the speech-dispatcher package than rather NOT ship an init
file? Does it make sense in some setups? An when speech-dispatcher has
no init file, maybe than speechd-up shouldn't "Required-Start"
speech-dispatcher in its init file. Not that it matters, it still
doesn't work when I do that.

May it be that starting daemons via service may not have $HOME set? It
occurs to me that when I start speechd-up manually I see this with "ps
aux" (notice the socket location):
root     22182  0.0  0.0 174708  2224 ?        Ssl  19:47   0:00
/usr/bin/speech-dispatcher --spawn --communication-method unix_socket
--socket-path /root/.cache/speech-dispatcher/speechd.sock

By the way, with "service" it seems that configuration of
speech-dispatcher is ignored. I find the logging in
/root/.cache/speech-dispatcher... where it now also records what goes
wrong..
[Fri Apr 21 20:04:39 2017 : 549750] speechd: Error [speechd.c:665]:No
speech output modules were loaded - aborting...

I'll try to figure out further.

Paul

Hi,
the init.d env. It's just LC_*/LANG, PATH, PWD, TERM; but adding HOME
doesn't help as far as I can tell.
$XDG_RUNTIME_DIR as referenced in /etc/speech-dispatcher/speechd.conf
isn't set in either env.

Looking at the log files, esp.
/root/.cache/speech-dispatcher/log/speech-dispatcher.log, I noticed
that running "sudo /etc/init.d/speechd-up start" works without errors.
Please note: I do not have and use systemd right now.
With systemd in use, this won't work, systemd catches the init script.
Running "sudo service speechd-up start" fails and this log shows a lot
of pulseaudio errors with the sub logs all logging this line:
pulse.c: pa_simple_new() failed: Connection refused

Looks like we're chasing a pulseaudio<->speech-dispatcher bug now. Fun.
Removing pulseaudio and setting AudioOutputMethod to alsa in
/etc/speech-dispatcher/speechd.conf makes speechd-up work.
After rebooting I can hear parts of the boot log messages, and:
$ sudo service speechd-up status
[ ok ] Checking status of Interface between speakup and speech-dispatcher: speechd-up running.

The directories are different when starting at boot:
$ ps aux | grep "speec\h"
root      1479  0.0  0.0  99264  2164 ?        Ssl  Apr21   0:00 /usr/bin/speechd-up -l1
root      1506  0.0  0.1  59768  4628 ?        SLl  Apr21   0:00 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
root      1533  0.0  0.1  59784  4612 ?        SLl  Apr21   0:00 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
root      1541  0.1  0.4 277456 10328 ?        SLl  Apr21   0:01 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
root      1586  0.0  0.0 173032  2212 ?        Ssl  Apr21   0:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /.cache/speech-dispatcher/speechd.sock
$ sudo service speechd-up restart
[....] Restarting Interface between speakup and speech-dispatcher: speechd-upStopping speechd-up and unloading speakup modules...
[Sat Apr 22 00:02:55 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Starting speechd-up...
To work, speechd-up needs speakup and speakup_soft modules.
They are loaded automatically. If you don't want, type
rmmod speakup speakup_soft
. ok
$ ps aux | grep "speec\h"
root      2170  0.0  0.1 105616  2744 ?        Ssl  00:02   0:00 /usr/bin/speechd-up -l1
root      2175  0.6  0.1  59776  4540 ?        SLl  00:02   0:00 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
root      2179  0.4  0.1  59788  4608 ?        SLl  00:02   0:00 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
root      2181  2.8  0.3 142088  8536 ?        SLl  00:02   0:00 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
root      2188  0.0  0.0 183144  2212 ?        Ssl  00:02   0:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock

Still a bit broken, but at least it's some progress.
At this stage, I think all these problems belong to speech-dispatcher.
I'll continue digging, but I I'll reset my vm after changing so much.

Just for the record:
I just found out that Jessie doesn't have any issues and the only
relevant changelog entry is "speechd-up.init: Fix startup/shutdown."
- well, for me it looks like the other way around.
Git commit: https://anonscm.debian.org/cgit/pkg-a11y/speechd-up.git/commit/?id=5db9503f13cdadbefb160846e53c8f141a7ee631
The errcode move is a legit bug fix.
STARTTIME might expose some bugs but isn't the root cause of anything.
Required-(Start|Stop) looks strange with the autospawn thing of
speech-dispatcher. But deleting speech-dispatcher from
Required-(Start|Stop) won't do anything - speech-dispatcher won't run
anyway unless enabled to do so in /etc/default/speech-dispatcher.
That's a dead-end, speechd-up doesn't seem to be the primary culprit.

[CC-ing tts-project@l.a.d.o as they are the maintainer of
speech-dispatcher; although I believe most contributers there also read
d-a11n.]

I concluded the same based on my logs. Although there the text was
different (3 times):
[Fri Apr 21 20:04:39 2017 : 454436] speechd:  Error: Module reported
error in request from speechd (code 3xx): 300-Opening sound device
failed. Reason: Couldn't open pulse plugin.
300 UNKNOWN ERROR

This doesn't sound good. I think it shouldn't matter how you call an
init-script, it should behave the same. I guess this is speechd-up's
responsibility.

Well, I am not 100% convinced. The directory for the socket apparently
comes from the environment, and I would say that that is the
responsibility of the caller (in this case speechd-up or its init-script).

I noticed the same.

Ack.

I came to the same conclusions in my previous e-mail. Good that we agree.

Agree. But I wonder if for the issue at hand (installation failing due
to init script failing) we should rather give up on providing an init
script that works in all circumstances for now. It seems it may rely on
configuration of speech-dispatcher (and sound). So maybe it is best for
now to just disable the init script (in a similar way as for
speech-dispatcher)?

If not, thant I propose to clone this bug for speech-dispatcher.
Cloning, because I think that the delta in socket path is something that
speechd-up should fix. But that is probably (if it does not actually
cause this issue) not RC. But than what would be the issue for
speech-dispatcher? "speech-dispatcher doesn't work with pulse-audio when
started from init-script"? That doesn't sound like a great thing.

What do others think?

Paul

Hi,

Might need some further testing, but imho that is speech-dispatcher's
problem, especially with the autospawn. I'd rather have
speech-dispatcher handle this correctly for all clients than make all
clients do the right thing (which they will inevitably fail to do).
Also, at the moment I think this happens only when not using systemd to
manage services. Still a bug though, especially because debian does
support other init systems.

Sounds like making this package quite useless and I think it's not
necessary. Fixing init script bugs should suffice.

I was thinking of reassigning to the current speech-dispatcher version
as "breaks with pulse output when spawned by speechd-up from init
system", keeping the RC level. Does this count as "breaking unrelated
packages"? I think so, but speechd-up and speech-dispatcher aren't
completely unrelated, so I'm unsure.
Without further input, I won't issue such bug control commands.
I'd rather open new bugs for any issues with speechd-up's init scripts
we find instead of cloning.

Like I announced, I did some further testing, but with a fresh debian
install now - the same base I used at the beginning, with systemd.
I can install speechd-up without any problem when I remove the
pulseaudio package, stop any running pa daemons, and configure
speech-dispatcher to use alsa instead before running apt install.
The installation succeeds without any warning, speechd-up is running
afterwards.

$ systemctl status speechd-up.service
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
   Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
   Active: active (running) since Sat 2017-04-22 20:40:19 CEST; 23s ago
     Docs: man:systemd-sysv-generator(8)
   CGroup: /system.slice/speechd-up.service
           ├─2267 /usr/bin/speechd-up -l1
           ├─2270 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
           ├─2272 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
           ├─2274 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
           └─2278 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock
$ ps aux | grep "speec\h"
root      2267  0.0  0.1 105616  2696 ?        Ssl  20:40   0:00 /usr/bin/speechd-up -l1
root      2270  0.0  0.1  59776  4504 ?        SLl  20:40   0:00 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
root      2272  0.0  0.1  59788  4540 ?        SLl  20:40   0:00 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
root      2274  0.0  0.3 142088  8580 ?        SLl  20:40   0:00 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
root      2278  0.0  0.0 183144  2168 ?        Ssl  20:40   0:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock

I then stopped speechd-up with systemctl and waited for
speech-dispatcher to terminate (as expected).

$ sudo systemctl start speechd-up.service
$ systemctl status speechd-up.service
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
   Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
   Active: active (running) since Sat 2017-04-22 20:51:21 CEST; 1min 22s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2335 ExecStop=/etc/init.d/speechd-up stop (code=exited, status=0/SUCCESS)
  Process: 2375 ExecStart=/etc/init.d/speechd-up start (code=exited, status=0/SUCCESS)
    Tasks: 13 (limit: 4915)
   CGroup: /system.slice/speechd-up.service
           ├─2387 /usr/bin/speechd-up -l1
           ├─2391 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
           ├─2393 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
           ├─2397 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
           └─2404 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock
$ ps aux | grep "speec\h"
root      2387  0.0  0.1 105616  2896 ?        Ssl  20:51   0:00 /usr/bin/speechd-up -l1
root      2391  0.0  0.1  59776  4528 ?        SLl  20:51   0:00 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
root      2393  0.0  0.1  59788  4664 ?        SLl  20:51   0:00 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
root      2397  0.1  0.3 142088  8536 ?        SLl  20:51   0:00 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
root      2404  0.0  0.0 183144  2284 ?        Ssl  20:51   0:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock

Rebooting the system.

$ systemctl status speechd-up.service
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
   Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
   Active: active (running) since Sat 2017-04-22 21:00:22 CEST; 24s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 13 (limit: 4915)
   CGroup: /system.slice/speechd-up.service
           ├─518 /usr/bin/speechd-up -l1
           ├─530 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
           ├─544 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
           ├─551 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
           └─589 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock
$ ps aux | grep "speec\h"
root       518  0.0  0.1 105616  2740 ?        Ssl  21:00   0:00 /usr/bin/speechd-up -l1
root       530  0.1  0.1  59776  4496 ?        SLl  21:00   0:00 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
root       544  0.1  0.1  59788  4592 ?        SLl  21:00   0:00 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
root       551  0.5  0.3 142088  8420 ?        SLl  21:00   0:00 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
root       589  0.0  0.0 183144  2300 ?        Ssl  21:00   0:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock

Yep, things are really working without pulseaudio and there aren't any
directory changes with systemd handling things. Logs are also there.
speechd-up is only breaking when speech-dispatcher is configured in a
special way, but sadly it's speech-dispatcher's default config.

Hi Cobra,

Good point. Agreed.

Agree, but if fixing the bug doesn't happen in time, it will drop out of
Stretch (at least if it remains with speechd-up). If we can't find the
real bug (and a solution), maybe having an init script that needs to be
enabled by the user is better than no speechd-up in Stretch. But see
below. (And what an incredible amount of work are we putting into this
package with a popcon of 9).

Please go ahead.

I don't think so. It breaks a very related package.

Please don't hesitate further.

Ok.

Ack.

Paul

Control: reassign -1 speech-dispatcher
Control: retitle -1 breaks with pulse-audio as output when spawned by speechd-up from init system
Control: affects -1 speechd-up

Summary for speech-dispatcher contributors:
speechd-up is failing to install (on several systems) because the
init script fails to start successfully. The success or failure of
starting speechd-up depends on
1) which output is used by speech-dispatcher, with alsa it work, but
   with the default pulse-audio it doesn't
2) how the speechd-up daemon is started, calling the init script fails
   but calling the exact same start-stop-daemon command manually on
   the command line succeeds.

The following remark may be spurious. While debugging, we
noticed that the directory that contains the speech-dispatcher socket
may depend on which init system is used. With systemd, it doesn't matter
how speechd-up is called, it puts the socket in
/root/.cache/speech-dispatcher/speechd.sock while with sysvinit-core upon
boot the socket is in
/.cache/speech-dispatcher/speechd.sock (after restarting it is in the same
directory as with systemd)

Paul

Hi,


Given delays, and to avoid autoremoval, maybe we could remove the
initscript so that the package to be iostallable? And documenting how to
run it manually?


Regards,



Le 23/04/2017 à 11:04, Paul Gevers a écrit :

Hi Jean-Philippe,

I proposed that already in this bug, but cobra convinced me to not do
that. Also, now the bug is assigned to speech-dispatcher, it will not
trigger autoremoval as speech-dispatcher is a key package¹. So let's
focus on getting the real bug solved.

Paul

¹ https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Le 23/04/2017 à 15:14, Paul Gevers a écrit :

ok sorry I had missed it. I just hope really the package speechd-up not
be removed. :)

Regards,

Hi,

did another test:
The installation and start/stop/restart of speechd-up work when
changing /etc/speech-dispatcher/speechd.conf from

# AudioOutputMethod "pulse"
to
AudioOutputMethod "pulse,alsa"

But doing so will break pulseaudio for users. There will be no audio
output from applications like vlc or firefox until speechd-up is
stopped. vlc is showing only "dummy output" instead of the usual
"Built-in Audio Analog Stereo" in Audio/Audio Device when speechd-up is
running.
Starting speechd-up after stopping it and using pulse as a user fails
until the running pulseaudio daemon is killed.
Switching vlc to use only alsa (both output module and device) works
with speechd-up running.

This whole issue looks very similar to #521675 (pulseaudio), note the
mention of speech-dispatcher which turned out to be the cause for one
user.
There are also #625235 and #670740 in speech-dispatcher.
A solution might be running pulseaudio as system-wide daemon. But I
don't know whether this is desirable or not, because there are some
downsides, including security implications.

Hi all,

Any progress on this issue? Seems like nobody is working on it. It also
looks like the underlaying issue (pulseaudio & speech-dispatcher
combination) has been known for years and hasn't received much
attention. Is the solution just not possible because it requires a
choice for the default of pulseaudio between non-secure and working, or
secure and non-working (given the goals and designs of the tools
involved)? And currently the behavior is more secure and thus not
working out of the box for pulseaudio users (but working for alsa users)?

Maybe the "solution" is to acknowledge the situation, disable the init
scripts by default (at least of speechd-up, although that would also
cause alsa users to not have speechd-up) and describe it properly in the
documentation (I originally wrote debconf, but I don't think that is
allowed), such that the user can be told how to fix it (I don't know,
but it seems that starting pulseaudio as system user may solve the issues).

Obviously, if we are convinced that what I describe above is correct,
then we could add some detection for alsa vs pulseaudio into the loop
(no idea how that would work and unsure which package(s) should do that).

Paul

Hi,

Unfortunately, it doesn't look like this will be fixed for buster...

Ivo

*Dear,I hope my email finds you in good health.Finally, i made it to
success with another partner after you couldn't complete the transaction
with me. But i did not forget your effort then, it  was part of my success
still. So i left a bank cheque with the Catholic Reverend sister whom i
told you about sometime ago as my trusted Secretary.Contact her at this
below email immediately, introduce yourself as the cashier cheque recipient
and demand for your cheque release process.Send email to: Reverend sister
Angela HelpeEmail:helperangela6@gmail.com
<Email%3Ahelperangela6@gmail.com>Tel:   +228 98766629*

*Dear,I hope my email finds you in good health.Finally, i made it to
success with another partner after you couldn't complete the transaction
with me. But i did not forget your effort then, it  was part of my success
still. So i left a bank cheque with the Catholic Reverend sister whom i
told you about sometime ago as my trusted Secretary.Contact her at this
below email immediately, introduce yourself as the cashier cheque recipient
and demand for your cheque release process.Send email to: Reverend sister
Angela HelpeEmail:helperangela6@gmail.com
<Email%3Ahelperangela6@gmail.com>Tel:   +228 98766629*

*Dear,I hope my email finds you in good health.Finally, i made it to
success with another partner after you couldn't complete the transaction
with me. But i did not forget your effort then, it  was part of my success
still. So i left a bank cheque with the Catholic Reverend sister whom i
told you about sometime ago as my trusted Secretary.Contact her at this
below email immediately, introduce yourself as the cashier cheque recipient
and demand for your cheque release process.Send email to: Reverend sister
Angela HelpeEmail:helperangela6@gmail.com
<Email%3Ahelperangela6@gmail.com>Tel:   +228 98766629*

*Dear,I hope my email finds you in good health.Finally, i made it to
success with another partner after you couldn't complete the transaction
with me. But i did not forget your effort then, it  was part of my success
still. So i left a bank cheque with the Catholic Reverend sister whom i
told you about sometime ago as my trusted Secretary.Contact her at this
below email immediately, introduce yourself as the cashier cheque recipient
and demand for your cheque release process.Send email to: Reverend sister
Angela HelpeEmail:helperangela6@gmail.com
<Email%3Ahelperangela6@gmail.com>Tel:   +228 98766629*

I looked into this a bit and came up with the attached patch (written
against 0.10.1-2), but for further improvement I'd need some feedback.

The patch adds a new thread that is on the lookout for Pulseaudio
processes and reconfigures/restarts the output modules accordingly
once it finds one.  This allows speech-dispatcher (with the correct
privileges) to transition between ALSA and Pulseaudio without the need
for a restart (albeit with the loss of the not-yet-spoken messages in
the module and a pause of about 1-2 seconds).  In my experience it
works quite nicely.

I don't doubt that making the output modules do the transition
themselves without restarting them would be better, but that would
require changes far more intrusive than the ones in this patch.

N.B.: For this to fix the original bug during installation of
speechd-up, the default for AudioOutputMethod would have to be changed
to "pulse,alsa".

Regards,
Dennis.

Hi Dennis, Samuel,

@Dennis, thanks a lot for working on this. Did you send this upstream as
well? If not, can you do it or do you prefer we do it?

@Samuel, what do you think of the patch. It's way to involved for me to
judge, but it claims to solve a long standing RC issue.

Paul

Hello,

Sorry for not answering before, I'm terribly busy atm. Just giving a
quick answer, a proper answer will need more time.

Paul Gevers, le sam. 17 oct. 2020 08:17:09 +0200, a ecrit:

Yes, the "pulse,alsa" user-visible change seems interesting.  But the
implementation seems fragile to me: looking in /proc content is deemed
to break at some point or another. We've been struck hard by such kind
of tinkering in the past, I'd rather not see that happen again :/

Samuel

Hi Samuel,

Did you have any chance to give this more thought? The bullseye freeze
is around the corner.

[...]

Ack. @Dennis, feel free to comment on this too.

Paul

I agree with the assessment that depending on /proc is far from ideal,
but I've been running it for a few months now and it's been working
better than I had expected.  However, the issues that I've encountered
so far mostly stem from a lack of integration.  For example, Orca is
started via /etc/xdg/autostart and pulseaudio in some cases via the
user's systemd, which means both are uncoordinated and thus race for
the audio device.  Another issue I've seen under Bullseye is that gdm3
makes its instance of pulseaudio give up control of the audio device
when the user switches to console which then mutes speakup if
speechd-up has already connected to pulseaudio, and there appears to
be no config option to turn that off.

I've also had some cases where speech-dispatcher pegs the CPU at 100 %
for some reason, but I haven't figured out the cause for that yet.
So, if this patch won't make it into Bullseye, it's not going to be
the end of the world.

The reason I started work on this in the first place is that AFAIK
Firefox some time ago dropped ALSA support and now only supports
pulseaudio.  Also to me it seems like the only way to implement
features like automatically picking up a phone call and routing speech
and phone audio to different ears or spatialization of arbitrary sound
sources.

Regards,
Dennis

You have an award from Newhouse Foundation. Contact Grant Officer: daniela.uhland00@gmail.com<mailto:daniela.uhland00@gmail.com>