Bug#859926: speechd-up: fails to install

[Dennis Filder]

On Mon, Jan 04, 2021 at 10:02:38PM +0100, Paul Gevers wrote:
> [...]
> > 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 :/
>
> Ack. @Dennis, feel free to comment on this too.

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

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi Samuel,

On 18-10-2020 18:05, Samuel Thibault wrote:
> Sorry for not answering before, I'm terribly busy atm. Just giving a
> quick answer, a proper answer will need more time.

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

[...]

>> @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.
> 
> 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 :/

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

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#859926: [Tts-project] Bug#859926: speechd-up: fails to install

[Samuel Thibault]

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:
> On 02-09-2020 17:46, Dennis Filder wrote:
> > 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.
> 
> @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.

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

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi Dennis, Samuel,

On 02-09-2020 17:46, Dennis Filder wrote:
> 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".

@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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Dennis Filder]

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.
Fix for #859926 

diff --git a/speech-dispatcher-0.10.1/src/server/configuration.c b/speech-dispatcher-0.10.1/src/server/configuration.c
index 3d08fe1..9457e3a 100644
--- a/speech-dispatcher-0.10.1/src/server/configuration.c
+++ b/speech-dispatcher-0.10.1/src/server/configuration.c
@@ -187,6 +187,7 @@ GLOBAL_FDSET_OPTION_CB_STR(DefaultModule, output_module)
 GLOBAL_FDSET_OPTION_CB_STR(AudioPulseServer, audio_pulse_server)
 GLOBAL_FDSET_OPTION_CB_STR(AudioPulseDevice, audio_pulse_device)
 GLOBAL_FDSET_OPTION_CB_INT(AudioPulseMinLength, audio_pulse_min_length, 1, "")
+GLOBAL_FDSET_OPTION_CB_INT(AudioPulseFallback, audio_pulse_fallback, 1, "")

 GLOBAL_FDSET_OPTION_CB_INT(DefaultRate, msg_settings.rate, (val >= -100)
 			   && (val <= +100), "Rate out of range.")
@@ -458,6 +459,7 @@ configoption_t *load_config_options(int *num_options)
 	ADD_CONFIG_OPTION(AudioPulseServer, ARG_STR);
 	ADD_CONFIG_OPTION(AudioPulseDevice, ARG_STR);
 	ADD_CONFIG_OPTION(AudioPulseMinLength, ARG_INT);
+	ADD_CONFIG_OPTION(AudioPulseFallback, ARG_INT);

 	ADD_CONFIG_OPTION(BeginClient, ARG_STR);
 	ADD_CONFIG_OPTION(EndClient, ARG_NONE);
@@ -494,6 +496,7 @@ void load_default_global_set_options()
 	GlobalFDSet.audio_pulse_server = g_strdup("default");
 	GlobalFDSet.audio_pulse_device = g_strdup("default");
 	GlobalFDSet.audio_pulse_min_length = 10;
+	GlobalFDSet.audio_pulse_fallback = 1;

 	SpeechdOptions.max_history_messages = 1;

diff --git a/speech-dispatcher-0.10.1/src/modules/Makefile.am b/speech-dispatcher-0.10.1/src/modules/Makefile.am
index 670c04c..3dcf920 100644
--- a/speech-dispatcher-0.10.1/src/modules/Makefile.am
+++ b/speech-dispatcher-0.10.1/src/modules/Makefile.am
@@ -28,9 +28,16 @@ audio_SOURCES = spd_audio.c spd_audio.h
 common_SOURCES = module_main.c module_utils.c module_utils.h
 common_LDADD = $(SNDFILE_LIBS) $(DOTCONF_LIBS) $(GLIB_LIBS) $(GTHREAD_LIBS)

+if pulse_support
+patrack = 1
+else
+patrack = 0
+endif
+
 AM_CFLAGS = $(ERROR_CFLAGS)
 AM_CPPFLAGS = $(inc_local) -DDATADIR=\"$(snddatadir)\" -D_GNU_SOURCE \
 	-DPLUGIN_DIR="\"$(audiodir)\"" \
+	-DPATRACK=\"$(patrack)\" \
 	$(DOTCONF_CFLAGS) $(GLIB_CFLAGS) $(GTHREAD_CFLAGS) \
 	$(ibmtts_include) $(SNDFILE_CFLAGS)

diff --git a/speech-dispatcher-0.10.1/src/server/Makefile.am b/speech-dispatcher-0.10.1/src/server/Makefile.am
index df15268..4f3e657 100644
--- a/speech-dispatcher-0.10.1/src/server/Makefile.am
+++ b/speech-dispatcher-0.10.1/src/server/Makefile.am
@@ -20,18 +20,26 @@
 inc_local = -I$(top_srcdir)/include/
 lib_common = $(top_builddir)/src/common/libcommon.la

+if pulse_support
+patrack = 1
+else
+patrack = 0
+endif
+
 bin_PROGRAMS = speech-dispatcher
 speech_dispatcher_SOURCES = speechd.c speechd.h server.c server.h \
 	history.c history.h module.c module.h configuration.c configuration.h \
 	parse.c parse.h set.c set.h msg.h alloc.c alloc.h \
 	compare.c compare.h speaking.c speaking.h options.c options.h \
 	output.c output.h sem_functions.c sem_functions.h \
+	patrack.c patrack.h \
 	index_marking.c index_marking.h symbols.c symbols.h
 speech_dispatcher_CFLAGS = $(ERROR_CFLAGS)
 speech_dispatcher_CPPFLAGS = $(inc_local) $(DOTCONF_CFLAGS) $(GLIB_CFLAGS) \
 	$(GMODULE_CFLAGS) $(GTHREAD_CFLAGS) -DSYS_CONF=\"$(spdconfdir)\" \
 	-DSND_DATA=\"$(snddatadir)\" -DMODULEBINDIR=\"$(modulebindir)\" \
 	-DLOCALE_DATA=\"$(localedatadir)\" \
+	-DPATRACK=\"$(patrack)\" \
 	-D_GNU_SOURCE -DDEFAULT_AUDIO_METHOD=\"$(default_audio_method)\"
 speech_dispatcher_LDFLAGS = $(RDYNAMIC)
 speech_dispatcher_LDADD = $(lib_common) $(DOTCONF_LIBS) $(GLIB_LIBS) \
diff --git a/speech-dispatcher-0.10.1/src/modules/module_utils.c b/speech-dispatcher-0.10.1/src/modules/module_utils.c
index 4f65dd3..c61db39 100644
--- a/speech-dispatcher-0.10.1/src/modules/module_utils.c
+++ b/speech-dispatcher-0.10.1/src/modules/module_utils.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include "module_utils.h"
+#include "sigabort.h"

 static char *module_audio_pars[10];

@@ -347,6 +348,8 @@ char 

Bug#859926: [Tts-project] Bug#859926: speechd-up: fails to install

[MENGUAL Jean-Philippe]

Le 23/04/2017 à 15:14, Paul Gevers a écrit :
> Hi Jean-Philippe,
> 
> On 23-04-17 13:47, MENGUAL Jean-Philippe wrote:
>> 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?
> 
> 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.

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

Regards,

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

-- 
Logo Hypra  
Photo Jean-Philippe MENGUAL *JEAN-PHILIPPE MENGUAL**
DIRECTEUR TECHNIQUE ET QUALITÉ*
adresse84, quai de Jemappes, 75010, Paris
téléphone+331 84 71 06 61 
courieljpmeng...@hypra.fr
site webwww.hypra.fr
Facebook Hypra Twitter Hypra
Linkedin

Bug#859926: [Tts-project] Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi Jean-Philippe,

On 23-04-17 13:47, MENGUAL Jean-Philippe wrote:
> 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?

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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[MENGUAL Jean-Philippe]

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 :
> 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
>
> On 22-04-17 22:01, Paul Gevers wrote:
>> On 22-04-17 21:26, Cobra wrote:
>>> 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.
>> Please go ahead.
> Done so now. Let's not wait unnecessary.
>
> 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
>

-- 
signature_jp
Logo Hypra  
Photo Jean-Philippe MENGUAL *JEAN-PHILIPPE MENGUAL**
DIRECTEUR TECHNIQUE ET QUALITÉ*
adresse84, quai de Jemappes, 75010, Paris
téléphone+331 84 71 06 61 
courieljpmeng...@hypra.fr
site webwww.hypra.fr
Facebook Hypra Twitter Hypra
Linkedin

Bug#859926: speechd-up: fails to install

[Paul Gevers]

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

On 22-04-17 22:01, Paul Gevers wrote:
> On 22-04-17 21:26, Cobra wrote:
>> 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.
> 
> Please go ahead.

Done so now. Let's not wait unnecessary.

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



signature.asc
Description: OpenPGP digital signature

Processed: Re: Bug#859926: speechd-up: fails to install

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 speech-dispatcher
Bug #859926 [speechd-up] speechd-up: fails to install
Bug reassigned from package 'speechd-up' to 'speech-dispatcher'.
No longer marked as found in versions speechd-up/0.5~20110719-6.
Ignoring request to alter fixed versions of bug #859926 to the same values 
previously set
> retitle -1 breaks with pulse-audio as output when spawned by speechd-up from 
> init system
Bug #859926 [speech-dispatcher] speechd-up: fails to install
Changed Bug title to 'breaks with pulse-audio as output when spawned by 
speechd-up from init system' from 'speechd-up: fails to install'.
> affects -1 speechd-up
Bug #859926 [speech-dispatcher] breaks with pulse-audio as output when spawned 
by speechd-up from init system
Added indication that 859926 affects speechd-up

-- 
859926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859926
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi Cobra,

On 22-04-17 21:26, Cobra wrote:
> On 2017-04-22 19:51, Paul Gevers wrote:
>> On 22-04-17 00:26, Cobra wrote:
>>> The directories are different when starting at boot:
>> 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.
>>> At this stage, I think all these problems belong to speech-dispatcher.
>> 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).
> 
> 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).

Good point. Agreed.

>>> That's a dead-end, speechd-up doesn't seem to be the primary culprit.
>> 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)?
> 
> Sounds like making this package quite useless and I think it's not
> necessary. Fixing init script bugs should suffice.

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).

> 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.

Please go ahead.

> Does this count as "breaking unrelated
> packages"? I think so, but speechd-up and speech-dispatcher aren't
> completely unrelated, so I'm unsure.

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

> Without further input, I won't issue such bug control commands.

Please don't hesitate further.

> I'd rather open new bugs for any issues with speechd-up's init scripts
> we find instead of cloning.

Ok.

> 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.

Ack.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Cobra]

Hi,

On 2017-04-22 19:51, Paul Gevers wrote:
> On 22-04-17 00:26, Cobra wrote:
>> The directories are different when starting at boot:
> 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.
>> At this stage, I think all these problems belong to speech-dispatcher.
> 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).

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.

>> That's a dead-end, speechd-up doesn't seem to be the primary culprit.
> 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)?

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

> 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.

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)
 

Bug#859926: speechd-up: fails to install

[Paul Gevers]

[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.]

On 22-04-17 00:26, Cobra wrote:
> Looks like we're chasing a pulseaudio<->speech-dispatcher bug now. Fun.

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

> The directories are different when starting at boot:

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.

> At this stage, I think all these problems belong to speech-dispatcher.

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).

> 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.

I noticed the same.

> The errcode move is a legit bug fix.

Ack.

> 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.

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

> That's a dead-end, speechd-up doesn't seem to be the primary culprit.

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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi

On 21-04-17 16:21, Cobra wrote:
> The man page states:
> "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.

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.

> 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:

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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi Jean-Philippe,

On 19-04-17 22:28, MENGUAL Jean-Philippe wrote:
> 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.

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?)

> 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?

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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[MENGUAL Jean-Philippe]

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 :
> On 4/18/17, Paul Gevers  wrote:
>> 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.
> 
> 
> 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 :)
> 

-- 
Logo Hypra  
Photo Jean-Philippe MENGUAL *JEAN-PHILIPPE MENGUAL**
DIRECTEUR TECHNIQUE ET QUALITÉ*
adresse84, quai de Jemappes, 75010, Paris
téléphone+331 84 71 06 61 
courieljpmeng...@hypra.fr
site webwww.hypra.fr
Facebook Hypra Twitter Hypra
Linkedin

Bug#859926: speechd-up: fails to install

[Cindy-Sue Causey]

On 4/18/17, Paul Gevers  wrote:
> 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.


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 :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Bug#859926: speechd-up: fails to install

[Paul Gevers]

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




signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Cindy-Sue Causey]

On 4/17/17, MENGUAL Jean-Philippe  wrote:
> 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.
>

Hi.. I follow accessibility lists and thought I recognized this as a
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. :)


> Le 16/04/2017 à 22:17, Paul Gevers a écrit :
>> Hi
>>
>> On 16-04-17 21:51, Paul Gevers wrote:
>>> I haven't figured out the difference yet.
>>
>> 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.


#ThankYou for the work you all do!

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi Jean-Philippe,

On 17-04-17 11:19, MENGUAL Jean-Philippe wrote:
> 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.

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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[MENGUAL Jean-Philippe]

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
> 
> On 16-04-17 21:51, Paul Gevers wrote:
>> I haven't figured out the difference yet.
> 
> 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
> 

-- 
Logo Hypra  
Photo Jean-Philippe MENGUAL *JEAN-PHILIPPE MENGUAL**
DIRECTEUR TECHNIQUE ET QUALITÉ*
adresse84, quai de Jemappes, 75010, Paris
téléphone+331 84 71 06 61 
courieljpmeng...@hypra.fr
site webwww.hypra.fr
Facebook Hypra Twitter Hypra
Linkedin





signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi

On 16-04-17 21:51, Paul Gevers wrote:
> I haven't figured out the difference yet.

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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi all,

On 16-04-17 11:32, Cobra wrote:
> I did some tests and installing speechd-up failed the same way.

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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Mika Hanhijärvi]

Hello


On 04/09/2017 10:10 PM, Samuel Thibault wrote:

Control: retitle -1 speechd-up: fails to install

Hello,

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

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

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




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

Bug#859926: speechd-up: fails to install

[Samuel Thibault]

Control: retitle -1 speechd-up: fails to install

Hello,

Mika Hanhijärvi, on dim. 09 avril 2017 13:42:36 +0300, wrote:
> 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

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

Processed: Re: Bug#859926: speechd-up: fails to install

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 speechd-up: fails to install
Bug #859926 [speechd-up] fails to install
Changed Bug title to 'speechd-up: fails to install' from 'fails to install'.

-- 
859926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859926
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems