Re: [orca-list] Announcing Speech Switch: making Linux a hospitable place for TTS engines like Voxin

[Bill Cox <waywardgeek gmail com>]

I agree, including the sd_voxin source would help a lot.  I tried to recompile sd_voxin from the Oralux git repo, but there appears to be some functions missing from the code base (e.g. voxToString).  The pre-built binary returns 21 from main, but I don't see code that could have generated that error, and since I can't rebuild it fromk source, I can't debug it.  The older sd_ibmtts engine is reading all the `PF commands to control the punctuation of ibmtts as characters, rather than setting punctuation, which is anoying, but I can live with it for now.

I run a beta version of Google's internal Debian-based Linux so that when a11y breaks I can help fix it before it hits all our blind Googlers who use our internal distro.  Espeak works fine, but I think most of us rely on Voxin.  I don't have any ideas for fixing the problem without access to the full sd_voxin source, so I'm writing a new Speech-Dispatcher module, which I'm calling speechsw.  I've got a portable binary for ibmtts that works from the command line, so I just need to finish the speechsw module to have a more stable alternative folks can fall back to when sd_voxin stops working.

I hope I can work with the Speech-Dispatcher deves to offer this new module bundled in Speech-Dispatcher once it is ready and the code is approved by the team.  The main benefit is the ability to copy the sub-modules I've built between distros and have them just work.  I currently put the sub modules are currently in /usr/lib/speechsw.  The new Speech-Dispatcher module talkes to the sub-modules over stdin/stdout, just like Speech-Dispatcher talks to modules.  If the new speechsw module were compiled for each release of each distro just like the Espeak modules, it should be reliable, and the binaries in /usr/lib/speechsw should work on any distro.

Anyway, this is the only way I currently see to get Eloquence working quickly on our internal Linux distro, and blind coworkers are likely to have their favorite TTS break soon.  I hope to have a solution for them in a few days.

On Thu, Dec 3, 2020 at 6:40 AM Alexandre ARNAUD <alexandre arnaud92 gmail com> wrote:

I 100% agree with what Samuel said. I don't think we need an alternative to Speech Dispatcher but coding effort to improve application we're using (Firefox, LibreOffice, etc).

Speech Dispatcher has never been hostile to commercial TTS, in the past years two proprietary speech synthesizer has been made compatible with it, I talk about Voxygen and the Kali TTS and I don't count Nuance Vocalizer one. I think the Oralux Vocalizer modules should be shipped with Speech Dispatcher to avoid compatibility issues in the future.
I think the main problem is the testing process and collaboration between different parties. We couldn't avoid all bugs even with the software you're writing. We couldn't request Samuel to do all the job itself to code and test every scenario of every users in its spare time.

If you've any proposal, don't hesitate to open pull request against Speech Dispatcher.

Le 02/12/2020 à 18:29, Samuel Thibault via orca-list a écrit :

Bill Cox via orca-list, le mer. 02 déc. 2020 08:27:18 -0800, a ecrit:

The problem is the architecture of Speech Dispatcher, which is hostile
to commercial TTS engines.

That's pure FUD. It is *not*, on the contrary!! The module approach
allows to integrate them by stuffing a binary in the right place.

The issues that we had with the voxin module were due to missing
*communication* and bugs, out of lack of testing. Creating *yet another*
speech server project will not help in that regard, and only bring
confusion to the accessibility stack.

It will also split the maintenance effort: speech dispatcher contains
symbol tables, drivers for various speech syntheses etc. Will you spend
the time to maintain all of this?

I don't see why creating yet another project. Why not just contributing
to the existing project?

Really, I don't understand, I can only interpret this as a slap in the
face and that cannot help me find motivation to continue contributing to
the accesibility stack (brlapi, orca braille driver, bugs in Xorg, bugs
in Wayland, etc.).

Really, can't we just work *together* rather that forking things here
and there yet again, bringing yet more confusion? Contribute code to
speech dispatcher and it'll just work. Did you actually try?

Samuel
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html