No way to configure SSML parsing to on for speech-dispatcher-espeak-ng

[guest271314]

Related #1

Attempting to set SSML parsing to on by default for Web Speech API at browsers 1) installed python3-speechd, removed espeak-ng, espeak, cloned espeak-ng from GitHub and added | espeakSSML to L344 at espeak-ng.c, built, installed and verified the installation

$ find /usr/* | grep libespeak-ng
/usr/lib/libespeak-ng.a
/usr/lib/libespeak-ng.la
/usr/lib/libespeak-ng.so
/usr/lib/libespeak-ng.so.1
/usr/lib/libespeak-ng.so.1.1.51
/usr/share/doc/libespeak-ng1
/usr/share/doc/libespeak-ng1/changelog.Debian.gz
/usr/share/doc/libespeak-ng1/copyright

and the output of the change to the source file

$ espeak-ng <speak>test</speak> parses the SSML by default, without passing -m flag, $ spd-say <speak>test</test> does not parse SSML without -x flag.

Looking into the source code further speech-dispatcher-espeak-ng package installs the file /usr/lib/speech-dispatcher-modules/sd_espeak-ng, which appears to be a self-contained version of espeak-ng unrelated to the version installed from the repository.

Kindly provide the steps necessary to either a) set the speech synthesis engine to the user selected local speech synthesis engine, instead of the file shipped with speech-dispatcher-espeak-ng; or b) set SSML parsing to on during $ spd-conf prompts and in ~/.config/speech-dispatcher/modules/espeak-ng.conf directly.

[sthibaul]

added | espeakSSML to L344 at espeak-ng.c

I you do not specify which version of speech-dispatcher you are using exactly, or giving URLs such as

speechd/src/modules/espeak-ng.c

Line 344 in 0ec6b72

espeak_Terminate();

(yes, that's what line 344 currentely is), I can not know what you are referring to.

espeak-ng test parses the SSML by default, without passing -m flag

? That is bogus, that does not happen so on my system, and shouldn't: If I don't pass -m, I'm hearing the speak tags. That is the documented and thus the expected behavior.

spd-say test does not parse SSML without -x flag.

Again, that's the documented, and thus expected behavior.

/usr/lib/speech-dispatcher-modules/sd_espeak-ng, which appears to be a self-contained version of espeak-ng unrelated to the version installed from the repository.

Not at all, it's a speech-dispatcher module, see objdump -x /usr/lib/speech-dispatcher-modules/sd_espeak-ng | grep NEED : it links again libespeak-ng, and other libraries used by speech-dispatcher (sndfile, dotconf, etc.)

set SSML parsing to on during $ spd-conf prompts

That looks like erroneous to me. Like I already told so in #1 , you can just enable ssml parsing during the connection. Allowing users to configure otherwise would provide confusion all over: applications expecting their speech text to be non-interpreted will see their input interpreted! Really, the only sane way is for clients to just tell whether their input has ssml or not. I don't see why clients can not just do that, it's in the SSIP protocol, you just need to pass SET SELF SSML_MODE on as documented in the speech-dispatcher manual. For the chromium case, see the patch I provided https://github.com/brailcom/speechd/files/1677168/ssml.txt

[sthibaul]

If you want to enable SSML by default only for your own experimentations, you can do so in src/server/configuration.c, load_default_global_set_options: set GlobalFDSet.ssml_mode = SPD_DATA_SSML instead of TEXT. But this is not a knob I'm willing to expose to users, that'd only bring even more to the confusion that WebSpeech seems to be having at the moment.

[guest271314]

you do not specify which version of speech-dispatcher you are using exactly, or giving URLs such as

https://github.com/espeak-ng/espeak-ng/blob/master/src/espeak-ng.c#L344

int synth_flags = espeakCHARS_AUTO | espeakPHONEMES | espeakENDPAUSE | espeakSSML;

is the simplest way that have tried and succeeded to enable SSML parsing by default.

? That is bogus

Do not post "bogus" content here, in any way, shape or form. All posts on any topic are supported by primary sources. In this case am the primary source.

that does not happen so on my system, and shouldn't: If I don't pass -m, I'm hearing the speak tags. That is the documented and thus the expected behavior.

The concept is to set SSML parsing on by default. That is the only use case. If markup is not expected to be parsed there are the entire world of speech synthesis engine applications and options to select from - not the version of espeak-ng that have built, the intended purpose is SSML input or plain text only.

Again, that's the documented, and thus expected behavior.

Not at all, it's a speech-dispatcher module

Well, espeak-ng.c has espeakSSML set by default - the expectated behaviour is for SSML parsing to be on by default and for speech-dispatcher to use the installed version of espeak-ng that modified - after this is FOSS code, one requirement can be different from some one else's requirement. Otherwise, there is no point to open source code; there would only be one file that never is changed, and thus no reason for GitHub and commits to change code that has only one expectation.

you can just enable ssml parsing during the connection.

How to do that? Does not appear to be possible.

Allowing users to configure otherwise would provide confusion all over: applications expecting their speech text to be non-interpreted will see their input interpreted!

The branch am building, or intending to build has a single purpose: SSML parsing on by default. There is zero confusion.There is a clear, concise and single purpose for the application. Again, if the user wants speech synthesis without SSML parsing on by default, they have the entire FOSS and proprietary market to select from, as AFAICT no speech synthesis engines are shipped with SSML parsing on by default.

Really, the only sane way is for clients to just tell whether their input has ssml or not. I don't see why clients can not just do that, it's in the SSIP protocol, you just need to pass SET SELF SSML_MODE on as documented in the speech-dispatcher manual. For the chromium case, see the patch I provided https://github.com/brailcom/speechd/files/1677168/ssml.txt

Absolutely agree. The patch graciously provided at https://bugs.chromium.org/p/chromium/issues/detail?id=795371#c18 / https://github.com/brailcom/speechd/files/1677168/ssml.txt/ is sitting un-used. Will try again to request a user with write access to Chromium source code to apply the patch.

If you want to enable SSML by default only for your own experimentations, you can do so in src/server/configuration.c, load_default_global_set_options: set GlobalFDSet.ssml_mode = SPD_DATA_SSML instead of TEXT. But this is not a knob I'm willing to expose to users, that'd only bring even more to the confusion that WebSpeech seems to be having at the moment.

Ok. Will try to find the file and setting.

There is no confusion. There is a specification that not address key aspects of the application, no algorithms, and yet the specification has not been replaced with language and code that does what is expected right now, in this day and age, given the state of the art - which would probably take the same amount of energy as dealing with the current specification.

Have created several other workarounds, including, for example, this proof-of-concept https://gist.github.com/guest271314/59406ad47a622d19b26f8a8c1e1bdfd5.

Am not sitting around waiting for someone else to do something regarding this matter.

[guest271314]

Re

Allowing users to configure otherwise would provide confusion all over: applications expecting their speech text to be non-interpreted will see their input interpreted! Really, the only sane way is for clients to just tell whether their input has ssml or not.

But this is not a knob I'm willing to expose to users, that'd only bring even more to the confusion that WebSpeech seems to be having at the moment.

The specification actually does include the language either so there should be no confusion, per the specification.

4.2.4. SpeechSynthesisUtterance Attributes

text attribute, of type DOMString
This attribute specifies the text to be synthesized and spoken for this utterance. This may be either plain text or a complete, well-formed SSML document. [SSML] For speech synthesis engines that do not support SSML, or only support certain tags, the user agent or speech engine must strip away the tags they do not support and speak the text. There may be a maximum length of the text, it may be limited to 32,767 characters.

Emphasis added.

The problem is implementers have ignored that language even when the patch to achieve the "either" part of the specification are available.

[sthibaul]

you do not specify which version of speech-dispatcher you are using exactly, or giving URLs such as

https://github.com/espeak-ng/espeak-ng/blob/master/src/espeak-ng.c#L344

int synth_flags = espeakCHARS_AUTO | espeakPHONEMES | espeakENDPAUSE | espeakSSML;

is the simplest way that have tried and succeeded to enable SSML parsing by default.

Ah! You were talking about espeak-ng's source, not speech-dispatcher's source. Thus why your espeak-ng command is behaving differently than mine

? That is bogus

Do not post "bogus" content here, in any way, shape or form. All posts on any topic are supported by primary sources. In this case am the primary source.

I was not saying you were not getting that behavior from espeak-ng. I was saying that espeak-ng having that behavior was bogus, since it is not what is documented. Now knowing that you patched your espeak-ng, I understand where the behavior difference is coming from: you modified it. And yes I will still call that behavior of espeak-ng as bogus since it's not what is document, not what it has been doing in the past etc. so doing such a change would bring more harm than good.

that does not happen so on my system, and shouldn't: If I don't pass -m, I'm hearing the speak tags. That is the documented and thus the expected behavior.

The concept is to set SSML parsing on by default.

Could you read about XY problems? (https://en.wikipedia.org/wiki/XY_problem). You are asking me X (SSML by default) which will not happen because that'd bring way more harm than good. So get back to the actual goal, Y.

What you want is to get SSML interpreted when chromium/firefox passes data over to speech-dispatcher. Okay, then make them actually express that it is ssml by toggling the proper bit. Trying to do it another way will just bring confusion whether data is pure text not to be interpreted, or text to be interpreted as ssml.

That is the only use case. If markup is not expected to be parsed there are the entire world of speech synthesis engine applications and options to select from - not the version of espeak-ng that have built, the intended purpose is SSML input or plain text only.

I couldn't understand what you meant.

Not at all, it's a speech-dispatcher module

Well, espeak-ng.c has espeakSSML set by default

Here I guess you are talking about the speech-dispatcher module source. Yes, SSML is enabled in that module. The idea in the speech-dispatcher structure is that speech-dispatcher modules are always passed SSML. If some synth backend doesn't support SSML, then module_strip_ssml is called in order to drop the SSML tags so they are not spoken out.

But the idea is also that if a client doesn't enable SSML when it connects to speech-dispatcher, non-SSML mode is assumed, and thus if there are SSML tags they get escaped, so that they properly get spoken out (e.g. a programmer reading some text with SSML tags, in that case we want tags to be spoken).

That last behavior has always been the behavior of speech-dispatcher. We definitely do not want to change that, because that would break a lot of existing software, and bring confusion as to what is text and what is ssml. Really, we don't want that, we have seen the kind of mess that kind of approach made in the charset questions.

• the expectated behaviour is for SSML parsing to be on by default

No. No, and no. It has never been so, so we do not want to suddenly change this.

Otherwise, there is no point to open source code;

"open source" doesn't mean we shouldn't set on sane basics. Making something that used to behave some way suddenly change its behavior is really not something we want, be it open or closed source.

you can just enable ssml parsing during the connection.

How to do that? Does not appear to be possible.

I already said so: it's in the SSIP protocol, just enable SSML. Modify the client that connects to speech-dispatcher. That's the only sane approach.

Allowing users to configure otherwise would provide confusion all over: applications expecting their speech text to be non-interpreted will see their input interpreted!

The branch am building, or intending to build has a single purpose: SSML parsing on by default. There is zero confusion. There is a clear, concise and single purpose for the application.

And where will it be deployed? Will it be visible publicly? Who will be using it? Will these users also use the same speech-dispatcher to run their own desktop? How will people know which branch they are running?

There is no confusion. There is a specification that not address key aspects of the application,

IT COMPLETELY DOES. You just have to enable the SSML mode when connecting to speech-dispatcher.

no algorithms, and yet the specification has not been replaced with language and code that does what is expected right now, in this day and age, given the state of the art - which would probably take the same amount of energy as dealing with the current specification.

Again, I don't see what you are meaning here.

But what is sure is that you seem to underestimate the amount of energy to deal with the confusion brought by enabling ssml by default while it has never been by default before. Really, look at the charset mess that we have in emails, it's been dozens of years, and we still have issues everywhere.

[sthibaul]

But this is not a knob I'm willing to expose to users, that'd only bring even more to the confusion that WebSpeech seems to be having at the moment.

The specification actually does include the language either so there should be no confusion, per the specification.

4.2.4. SpeechSynthesisUtterance Attributes

text attribute, of type DOMString
This attribute specifies the text to be synthesized and spoken for this utterance. This may be either plain text or a complete, well-formed SSML document.

URRRRGL.

So it's the API which is screwed. See, here is precisely the confusion: how are we supposed to know whether the text has to be interpreted as plain text or as SSML? A plain text can very well contain <speak>foo</speak>, and that's what the synthesis should speak it that case: "speak foo slash speak".

That speech API needs to be fixed to add an attribute to specify whether this is SSML or not. There is no other sane way, really.

Really this is just like character sets, you do not want any other way than actually specify which encoding is used.

[SSML] For speech synthesis engines that do not support SSML, or only support certain tags, the user agent or speech engine must strip away the tags they do not support and speak the text.

Yes, and speech-dispatcher does that if the client enables SSML, but the synthesis backend doesn't actually support it. So just make your speech-dispatcher client enable SSML, and you will have everything working appropriately.

The problem is implementers have ignored that language even when the patch to achieve the "either" part of the specification are available.

The problem is in the spec. Implementers have no way to know when SSML should be enabled or not.

[guest271314]

Could you read about XY problems? (https://en.wikipedia.org/wiki/XY_problem). You are asking me X (SSML by default) which will not happen because that'd bring way more harm than good. So get back to the actual goal, Y.

Not an "XY" problem. SSML can be parsed. If there are SSML tags, output SSML, otherwise just parse the plain text. The problem already exists. Am not creating it looking for a solution. Re

I couldn't understand what you meant.

the version of espeak-ng with speech-dispatcher that am attempting to build will have SSML parsing turned on by default. That is the only purpose. Plain text can still get parsed. If we could supply our own SSML parsers https://github.com/guest271314/SpeechSynthesisSSMLParser, even better, to avoid the edge cases of other SSML parsers espeak-ng/espeak-ng#737.

Consider the command $ espeak-ng -m --stdout <text_or_ssml> where input can be in the form of "plain text" or <speak>plain text</speak> though for the purposes of addressing your concern the application will be clearly marked and user notifiied: expects SSML input.

URRRRGL.

So it's the API which is screwed. See, here is precisely the confusion: how are we supposed to know whether the text has to be interpreted as plain text or as SSML? A plain text can very well contain foo, and that's what the synthesis should speak it that case: "speak foo slash speak".

That speech API needs to be fixed to add an attribute to specify whether this is SSML or not. There is no other sane way, really.

Again, agree. WICG/speech-api#10, web-platform-tests/wpt#8712. However, changes have not been made. The motion of the ocean does not stop: the requirement has not been met, therefore proceed until achieve goal, by any means.

[guest271314]

Good luck trying to change the Web Speech API specification. When tried to contribute was advied to join W3C and WICG, which reluctantly did, as do not need a group hug to accomplish tasks and institutions have issues outside of the technical issue that am focused on. They did not like /guest271314/ as a "name", and when told them they did not define "real name", while having other contributers with their own version of a "real name", thus clear hypocrisy, was banned froom WICG for 1,000 years w3c/mst-content-hint#39 (comment), w3c/mediacapture-main#629 (comment).

The problem is in the spec. Implementers have no way to know when SSML should be enabled or not.

True. The Web Speech API is dead, though that is all we have at the front-end without trying to use WASM and Emscripten, which is a treat to try at 32-bit architecture.

While you are here, can you kindly reference how to build speech-dispatcher again, so can modify configuration.c, replace apt installed version and try that?

[guest271314]

Full disclosure: TL;DR WICG/speech-api#67; https://lists.w3.org/Archives/Public/public-wicg/2019Oct/0000.html.

[sthibaul]

Could you read about XY problems? (https://en.wikipedia.org/wiki/XY_problem). You are asking me X (SSML by default) which will not happen because that'd bring way more harm than good. So get back to the actual goal, Y.

Not an "XY" problem.

Yes, it is. X: "enable SSML by default in speech-dispatcher". Y: "have SSML text coming from speech API interpreted as SSML".

SSML can be parsed. If there are SSML tags, output SSML, otherwise just parse the plain text. The problem already exists. Am not creating it looking for a solution.

And I'm saying that your solution is just moving the problem, and will get other problems in other places.

I couldn't understand what you meant.

the version of espeak-ng with speech-dispatcher that am attempting to build will have SSML parsing turned on by default.

Then do like what I said in #301 (comment) , but again, that's not something that should be released publicly, since it changes behavior that has been stable for decades.

That is the only purpose. Plain text can still get parsed.

No, because enabling SSML parsing by default would bring confusion. If I'm typing

spd-say "<speak>Foo</speak>"

And I did mean this to be the plain text that happens to contain <speak>Foo</speak> your proposal breaks it.

URRRRGL.

So it's the API which is screwed. See, here is precisely the confusion: how are we supposed to know whether the text has to be interpreted as plain text or as SSML? A plain text can very well contain foo, and that's what the synthesis should speak it that case: "speak foo slash speak".
That speech API needs to be fixed to add an attribute to specify whether this is SSML or not. There is no other sane way, really.

Again, agree. WICG/speech-api#10, web-platform-tests/wpt#8712. However, changes have not been made. The motion of the ocean does not stop: the requirement has not been met, therefore proceed until achieve goal, by any means.

Sorry, but I can't buy "proceed by any means". Going fast by bringing confusion only means having to spend a lot of effort later on to fix the confusion. See this comment: WICG/speech-api#10 (comment) , it's exactly what I said: specify in the API whether the text is SSML or not.

While you are here, can you kindly reference how to build speech-dispatcher again, so can modify configuration.c, replace apt installed version and try that?

I'm sorry but it's already difficult for me to find the time to answer you, find the time to fix the pulseaudio bug which I believe was wrongly blamed on speech-dispatcher, find the time to at last release a 0.10, etc. while there is [email protected] etc. which are meant for this.

[guest271314]

Your feedback is valuable. Have been trying to get SSML input implemented by any means for a couple of years now.

As mentioned in the comments above, WICG banned this user, per their "discourse" site, for 1,000 years, from GitHub WICG subsidiaries, ostensibly indefinitely, because they did not like the "real name" /guest271314/. Thus, am not able to reply to you comment at WICG/speech-api#10 (comment).
.

I'm sorry but it's already difficult for me to find the time to answer you, find the time to fix the pulseaudio bug which I believe was wrongly blamed on speech-dispatcher, find the time to at last release a 0.10, etc. while there is [email protected] etc. which are meant for this.

No worries. Will continue to do what can here, again, by any means, as have no restrictions on own conduct relevant to achieving the requirement. YMMV trying to move the Web Speech API specification forward to write and therefrom for implementers to actually implement what is already possible, and has been since filed the first issue here. If the specification and browsers are not moving to achieve the requirement, even though the technology is readily available, the conclusion reached here is those bodies lack the will to do so, and am not bound by their restrictions or lack of will: yes, will continue to try to implement SSML parsing by any means. If after achieved the proof-of-concept can be made sane, will work on sorting out the parts to keep.

Kind regards,
/guest271314/

[guest271314]

Unfortunately trying to build from GitHub repository has some issues, autopoint is also a dependency

checking for DOTCONF... no
configure: error: Package requirements (dotconf >= 1.3) were not met:

No package 'dotconf' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables DOTCONF_CFLAGS
and DOTCONF_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


~/speechd$ autoreconf   -i
Can't exec "autopoint": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 345.
autoreconf: failed to run autopoint: No such file or directory
autoreconf: autopoint is needed because this package uses Gettext
~/speechd$ sudo apt install autopoint


make[2]: Entering directory '/path/to/speechd/doc'
  MAKEINFO ssip.info
/path/to/speechd/missing: line 81: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
         You should only need it if you modified a '.texi' file, or
         any other file indirectly affecting the aspect of the manual.
         You might want to install the Texinfo package:
         <http://www.gnu.org/software/texinfo/>
         The spurious makeinfo call might also be the consequence of
         using a buggy 'make' (AIX, DU, IRIX), in which case you might
         want to install GNU make:
         <http://www.gnu.org/software/make/>
Makefile:478: recipe for target 'ssip.info' failed
make[2]: *** [ssip.info] Error 127
make[2]: Leaving directory '/path/to/speechd/doc'
Makefile:587: recipe for target 'install-recursive' failed
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory '/path/to/speechd'
Makefile:887: recipe for target 'install' failed
make: *** [install] Error 2

Removed default installation of speech-dispatcher, ran sudo make install without apparent errors, though speech-dispatcher is not in PATH.

make all and sudo make install complete without errors, yet

~/speechd$ speech-dispatcher --help
bash: /usr/bin/speech-dispatcher: No such file or directory

[sthibaul]

autopoint and makeinfo are required dependencies only when you build from git, building from a tarball doesn't need it. People building from git are expected to know to install the additional dependencies.

$ speech-dispatcher --help
bash: /usr/bin/speech-dispatcher: No such file or directory

is /usr/local/bin in your $PATH ? Did you run hash -r to make sure that bash is not still trying to look for it in /usr/bin?

[guest271314]

Yes, /usr/local/bin is in $PATH

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Just installed the tarball!

~/Downloads/speech-dispatcher-0.10.0-rc3$ speech-dispatcher --help
Speech Dispatcher -- Common interface for Speech Synthesis (GNU GPL)

Usage: speech-dispatcher [-{d|s}] [-l {1|2|3|4|5}] [-c com_method] [-S socket_path] [-p port] [-t timeout] | [-v] | [-h]

Options: 
  -d, --run-daemon      Run as a daemon
  -s, --run-single      Run as single application
  -a, --spawn           Start only if autospawn is not disabled
  -l, --log-level       Set log level (between 1 and 5)
  -L, --log-dir         Set path to logging
  -c, --communication-method
                        Communication method to use ('unix_socket'
                        or 'inet_socket')
  -S, --socket-path     Socket path to use for 'unix_socket' method
                        (filesystem path or 'default')
  -p, --port            Specify a port number for 'inet_socket' method
  -t, --timeout         Set time in seconds for the server to wait before it
                        shuts down, if it has no clients connected
  -P, --pid-file        Set path to pid file
  -C, --config-dir      Set path to configuration
  -m, --module-dir      Set path to modules
  -v, --version         Report version of this program
  -D, --debug           Output debugging information into $TMPDIR/speechd-debug
                        if TMPDIR is exported, otherwise to /tmp/speechd-debug
  -h, --help            Print this info

Please report bugs to [email protected]

Uninstalled python3-speechd before began process, so would not mix things up. Still do not know what is the difference between speech-dispatcher and python3-speechd, though spd-conf evidently is not shipped with the tarball release?

$ spd-conf
Traceback (most recent call last):
  File "/usr/local/bin/spd-conf", line 22, in <module>
    import speechd_config
ModuleNotFoundError: No module named 'speechd_config'

Will installing python3-speechd using apt result in losing everything gained so far?

[sthibaul]

ModuleNotFoundError: No module named 'speechd_config'

Your system python apparently doesn't find what you installed in /usr/local/. You'd have to see what your system provides to enable using it. Possibly simply

export PYTHONPATH=/usr/local/lib/python3.8/site-packages

or whatever path it got installed in.

Will installing python3-speechd using apt result in losing everything gained so far?

No, the python speechd library is essentially unchanged. The system-provided library will not be able to autospawn /usr/local/bin/speech-dispatcher, but you can spawn that by hand.

[guest271314]

spd-say is throwing an error

$ export PYTHONPATH=/usr/local/lib/python3.6/site-packages
~/Downloads/speech-dispatcher-0.10.0-rc3$ spd-conf

Speech Dispatcher configuration tool

Do you want to setup a completely new configuration? [yes] :
>yes
..
Do you want to start/restart Speech Dispatcher now and run some tests? [yes] :
>
Starting Speech Dispatcher in user-mode
[Sun May  3 21:49:34 2020 : 324004] speechd: Speech Dispatcher 0.10.0-rc3 starting
Testing Speech Dispatcher using spd_say
spd-say: symbol lookup error: spd-say: undefined symbol: spd_set_voice_pitch_range
Can't execute the spd-say binary,
it is very likely that Speech Dispatcher is not installed.

Speech Dispatcher isn't running or we can't connect to it (see above),
do you want to proceed with other tests? (They can help to determine
what is wrong) [yes] :
>

[sthibaul]

spd-say: undefined symbol: spd_set_voice_pitch_range
Can't execute the spd-say binary

Did you run ldconfig after make install?

One always has to do so, otherwise the system library cache still points at the system-provided library.

[guest271314]

No. Did not. Not in the build instructions. The reader could perhaps not be expected to know everything seasoned authors of the source run every day. If that information is critical, though not printed in instructions, could be printed anyway for double-redundancy, e.g., the tests reference run_test though the file is named run_test.c. Am still learning.

Can ldconfig be run now, or have to start over from scratch?

[guest271314]

$ ldconfig
/sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
~/Downloads/speech-dispatcher-0.10.0-rc3$ sudo ldconfig
~/Downloads/speech-dispatcher-0.10.0-rc3$ spd-say 'test'
spd-say: symbol lookup error: spd-say: undefined symbol: spd_set_voice_pitch_range

[sthibaul]

./configure && make && make install && ldconfig is a really normal thing to know when one is building packages by hand.

the tests reference run_test though the file is named run_test.c.

No it's really run_test, but you need to run make check to get it.

$ ldconfig
/sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied

/etc/ is root-only indeed.

[guest271314]

Same error

$ ./configure && make && sudo make install && sudo ldconfig

$ spd-say  'test'
spd-say: symbol lookup error: spd-say: undefined symbol: spd_set_voice_pitch_range

[sthibaul]

It's still looking for the system-provided library. I'd say check with your distribution how you are supposed to make libraries in /usr/local/lib actually work. Normally ldconfig is all you need to run.

[guest271314]

Ok. Would any options passed to ./configure help? Installing python3-speechd using apt now has same result.

I'd say check with your distribution how you are supposed to make libraries in /usr/local/lib actually work.

Will try that. Have already asked, you, the maintainer. Do not know how to solve the issue right now.

[guest271314]

BTW, there is no executable named spd-say in /usr/local/lib. What binary is actually being called for spd-say?

[sthibaul]

Would any options passed to ./configure help?

No, by default it installs to /usr/local/lib, which should work fine on Linux systems.

[sthibaul]

BTW, there is no executable named spd-say in /usr/local/lib

lib is for library. binaries are in bin

[guest271314]

Ok. Not working. Apparently chmod +x have no effect. Why does spd-conf work but not spd-say?

[guest271314]

Actually, spd-conf stalls at the test when spd-say is called

Testing Speech Dispatcher using spd_say
spd-say: symbol lookup error: spd-say: undefined symbol: spd_set_voice_pitch_range
Can't execute the spd-say binary,
it is very likely that Speech Dispatcher is not installed.

[sthibaul]

chmod +x on a library doesn't make sense. The executable is found. The library is not. See with your distribution help support for why it would not work there.

Your comment #301 (comment) shows that make install has properly put it in /usr/local/lib, i.e. where it shall be, and a ldconfig should be enough for making it recognized by the system.

Since apparently it doesn't work, it's a distro problem, so see with the distro

[guest271314]

https://ubuntuforums.org/showthread.php?t=2442447.

Who knew enabling SSML support in browsers where the technology, patch, and infrastructure exists to do so would not be as simple as applying the existing patch and installing the source code to facilitate said support?

[sthibaul]

Who knew [doing something far from simple with computers] would not be as simple as applying the existing patch

Computer science is almost never as simple as just applying a patch. Some patches really open big cans of worms, and we cannot afford that if we want to keep our software stacks maintainable and debuggable.

[guest271314]

Really is the same in any and all fields of human activity. Found that out through hard lessons first hand: litigating to SCOTUS twice by self; and independent research into various invented political classifications; i.e., vetting historical claims; which the former provided instruction therefore by way of statutory construction. Of course, neither individuals not institutions necessarily want their mythologies shredded https://plnkr.co/edit/5CwKsW?preview, thus have been banned from several sites and organizations, one for 1,000 years, some for 5 years, some indefinitely, like Twitter, evidently preemptively: "the algorithm did it" https://politics.meta.stackexchange.com/a/3509. Have been accused of being a Russian bot, and a racist for transcribing Gobineau by hand https://english.meta.stackexchange.com/q/12032 when researched and found the origin of the terms "white people" and later invention "White-women" (1681 Maryland Colony), "white races" and so-called "black" "race" and "race" itself. Primary sources are a must https://history.stackexchange.com/a/47942, emotional responses and some erroneous idea of "respect" are not a must. Too many examples of censored questions and answers and bans to list here https://github.com/guest271314/banned. Am well-suited to handle several years on a computer project after contesting an entire State in a nation-state venue.

Computer science is almost never as simple as just applying a patch. Some patches really open big cans of worms, and we cannot afford that if we want to keep our software stacks maintainable and debuggable.

Essentially, your stance is extendable to all disciplines. Expect that if the result is not reproducible by the scientific method, or the claim is not backed by primary sources, will be exposing that fraud forthwith if in this midst, without exception. E.g., institutions cannot claim to be awaiting on WHO to tell them about some "new" virus when an admin. agency of that institution has funded research into that very subject matter since at least 2014 https://taggs.hhs.gov/Detail/AwardDetail?arg_AwardNum=R01AI110964&arg_ProgOfficeCode=104.

[sthibaul]

Essentially, your stance is extendable to all disciplines

Well, yes, sure. Anything complex is complex to achieve, yes, sure.

[guest271314]

Progress.

$ sudo apt --purge remove libspeechd2 speech-dispatcher-audio-plugins

However, now $ spd-say 'test' does output audio but only outputs "dummy" module, even after running spd-conf where espeak-ng is set as the module.

[sthibaul]

See the daemon logs, they are probably in /run/user/your_uid/speech-dispatcher/log

[guest271314]

[Mon May  4 00:55:16 2020 : 179698] speechd:   Speech Dispatcher Logging to file /run/user/your_uid/speech-dispatcher/log//speech-dispatcher.log
[Mon May  4 00:55:16 2020 : 179740] speechd:   Speech Dispatcher started with 1 output module
[Mon May  4 00:55:16 2020 : 180115] speechd: Speech Dispatcher started and waiting for clients ...
[Mon May  4 00:55:16 2020 : 180624] speechd: Failed to open file '/usr/local/share/speech-dispatcher/locale/c/emojis.dic': No such file or directory
[Mon May  4 00:55:16 2020 : 180640] speechd: Failed to open file '/usr/local/share/speech-dispatcher/locale/c/gender-neutral.dic': No such file or directory
[Mon May  4 00:55:16 2020 : 180650] speechd: Failed to open file '/usr/local/share/speech-dispatcher/locale/c/font-variants.dic': No such file or directory
[Mon May  4 00:55:16 2020 : 180661] speechd: Failed to load symbols
[Mon May  4 00:55:16 2020 : 180670] speechd:   Warning: Didn't find preferred output module, using default
[Mon May  4 00:55:16 2020 : 180677] speechd:   Couldn't load default output module, trying other modules
[Mon May  4 00:55:21 2020 : 147791] speechd: Terminating...
[Mon May  4 00:55:21 2020 : 147824] speechd:  Closing open connections...
[Mon May  4 00:55:21 2020 : 148337] speechd:  Closing open output modules...
[Mon May  4 00:55:21 2020 : 148365] speechd:   Unloading module name=dummy
[Mon May  4 00:55:21 2020 : 148383] speechd:   Closing module "dummy"...
[Mon May  4 00:55:21 2020 : 148769] speechd: ERROR: waitpid() failed when waiting for child (module).
[Mon May  4 00:55:21 2020 : 148812] speechd:  Closing server connection...
[Mon May  4 00:55:21 2020 : 148899] speechd:  Speech Dispatcher terminated correctly

when trying to use ./configure --with-espeak-ng

checking for espeak_Synth in -lespeak... no
checking for ESPEAK_NG... no
configure: error: in `/path/to/speech-dispatcher-0.10.0-rc3':
configure: error: espeak-ng is not available
See `config.log' for more details

that is both with apt version and version installed from espeak-ng GitHubb repository.

[guest271314]

Chromium does not autospawn connection when --enable-speech-dispatcher flag is set or at least no voices are ever loaded, and Task Manager shows the connection closes, is not running as a server always on.

[sthibaul]

See `config.log' for more details

[guest271314]

config.log

Not certain what looking for?

[sthibaul]

Looking for espeak-ng:

configure:21029: $PKG_CONFIG --exists --print-errors "espeak-ng"
Package espeak-ng was not found in the pkg-config search path.
Perhaps you should add the directory containing `espeak-ng.pc'
to the PKG_CONFIG_PATH environment variable

Do you really have installed the package that provides the espeak-ng.pc file?

[guest271314]

Was trying with espeak-ng from GitHub repository. That did version not build correctly this time; probably due to using /.configure --prefix=/home/path/to/data which configure apparently remembers

 /bin/mkdir -p '/usr/bin'
  /bin/bash ./libtool   --mode=install /usr/bin/install -c src/speak-ng src/espeak-ng '/usr/bin'
libtool: install: /usr/bin/install -c src/speak-ng /usr/bin/speak-ng
libtool: warning: 'src/libespeak-ng.la' has not been installed in '/home/path/to/data/lib'

Re-installed using apt then $ ./configure --with-espeak-ng && sudo make && sudo make install && sudo ldconfig, then tested $ spd-say '<speak>test</speak>' and at console` after closing then opening Chromium 81

var u = new SpeechSynthesisUtterance();
undefined
u.text = '<speak><voice name="Storm">test</voice></speak>'
"<speak><voice name="Storm">test</voice></speak>"
speechSynthesis.speak(u);

and Nightly 77, where the listing of the voice name and lang properties of the SpeechSynthesisVoice are different

var u = new SpeechSynthesisUtterance();
u.text = '<speak><voice name="Storm">test</voice></speak>';
u.voice = speechSynthesis.getVoices().find(({name}) => name === 'English (Caribbean)+Kaukovalta');

speechSynthesis.speak(u);

Nightly lists lang as, e.g., "en-GB-SCOTLAND-NORBERT" and name as "English (Scotland)+norbert" Chromium lists name as "English (Scotland)+norbert espeak-ng" and lang as "".

Success!

Thank you kindly for your time, energy, patience and professional maintenance over the course of this and several related issues at speech-dispatcher repository.