[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux 9 stretch What to do about reviving speakup?



Hi, I have been following this issue and just ran into this espeakup upgrading issue. Here is the full output of the configuration process and it looks like /bin is before sh in the systemd service espeakup file. I even purged both espeak and espeakup killing all processes and still got this error. Nick Gawronski
Setting up espeakup (1:0.80-14) ...
● espeakup.service - Software speech output for Speakup
   Loaded: loaded (/lib/systemd/system/espeakup.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 2019-04-09 13:12:53 CDT; 17ms ago
     Docs: man:espeakup(8)
  Process: 31914 ExecStart=/bin/sh -c modprobe speakup_soft && /usr/bin/espeakup -V "${VOICE}" (code=exited, status=219/CGROUP)
On Wed, 3 Apr 2019, Didier Spaier wrote:

Date: Wed, 3 Apr 2019 20:09:33 +0200
From: Didier Spaier <didier@slint.fr>
To: Samuel Thibault <sthibault@debian.org>
Cc: Debian Accessibility Team <debian-accessibility@lists.debian.org>,
    Speakup is a screen review system for Linux. <speakup@linux-speakup.org>
Subject: Re: Linux 9 stretch What to do about reviving speakup?
Resent-Date: Wed,  3 Apr 2019 18:09:49 +0000 (UTC)
Resent-From: debian-accessibility@lists.debian.org

Hello,

On 02/04/2019 23:08, Didier Spaier wrote:
On 02/04/2019 06:50, Samuel Thibault wrote:
It's not when it is loaded, but when switching from one to the other.
Unloading the module indeed avoids the issue, but that's still a manual
thing.

The bug is to be fixed in linux 5.0.6, 4.20.18, 4.19.33.

Thanks for the information Samuel.

So we shouldn't have to wait more than two days <smile>

We didn't have to In
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.33

I see:

commit 86092f2d5ccba5ea3ec98b17225b98dbfce225d6
Author: Samuel Thibault <hidden>
Date:   Thu Mar 7 23:06:57 2019 +0100

   staging: speakup_soft: Fix alternate speech with other synths

Thanks for this, Samuel!

That leads to some questions.

Currently in Slint:
1. We ship all speakup drivers built-in.
2. A user wanting to install using a hard synth must include in the boot
  command line:
  speakup.synth=<synth model>
3. During installation, if the word speakup is *not* found in
  /proc/cmdline, we start espeakup by defaut, which of course relies on
  speakup_soft, then ask the user if he or she wants to keep speech. if
  yes, espeakup will be started by default in the installed system.

Having read spkguide.txt I assume that if we use a kernel with all
speakup drivers shipped as modules, both in the installer (theses modules
being in this case shipped in the initrd) and the installed system, a
user of a hard synth will have to insert before booting the installer in
the boot command line:
 modprobe speakup <synth name>
And this should also be included in the boot command line of the
installed system (in grub.cfg).

Is this right?

Then, both in the installer and in the installed system, the main
startup script will also need to "modprobe speakup soft" before starting
espeakup, right?

But, with the changes you introduced, maybe we can
"modprobe speakup soft" unconditionally, i.e. even if a hard synth is
already in use? Is this implied by what I read in the commit:

When switching from speakup_soft to another synth, speakup_soft would
keep calling synth_buffer_getc() from softsynthx_read.

Let's thus make synth.c export the knowledge of the current synth, so
that speakup_soft can determine whether it should be running.

speakup_soft also needs to set itself alive, otherwise the switch would
let it remain silent

Or conversely, does that means that a user currently running espeakup
can plug in a hard synthesizer and switch to it after having modprobed
the relevant speakup module without having to unload speakup_soft first?

But then, does this change also allows espeakup to be used with a hard
synth, or does it remain usable only with the soft synth?

Thanks for shedding some light in my obscure mind.

Best,

Didier


Reply to: