brailcom/speechd

Speaking certain characters with sd_voxin makes speech-dispatcher unresponsive

Opened this issue · 13 comments

joanmarie commented

Step to reproduce

  1. In a terminal, enter the following:
$ spd-say -c -o espeak-ng "<"
$ spd-say -c -o espeak-ng "<"
$ spd-say -c -o voxin "<"
$ spd-say -c -o voxin "<"

Obtained behavior

With espeak-ng, the character is spoken each time and spd-say exits. With voxin, nothing is heard after the first attempt, but spd-say exits. With the second attempt, nothing is heard and spd-say does not exit. The sd_voxin process's CPU usage spikes to 100%. (Are there debugging symbols we can get our hands on? Output from gdb was useless.)

Expected behavior

The character would always be spoken, but failing that, spd-say wouldn't hang.

Environment, logs, etc.

  • The contents of my voxin.log is just a single line: Error opening configuration file '/etc/speech-dispatcher/modules/voxin.conf'. But voxin works fine (modulo this particular bug). For instance if I replace "<" with "h", the bug does not occur.
  • speech-dispatcher.log
  • Fedora 39, speech-dispatcher-0.11.5-1.fc39.x86_64
  • Voxin 3.3rc5 (Guess I should check if there's an update...)
sthibaul commented

Since sd_voxin comes from the Voxin package, that'd rather have to be discussed with the Voxin authors?

sthibaul commented

Note: to get more logs, you can put

Debug 1

in /etc/speech-dispatcher/modules/voxin.conf

sthibaul commented

What I can see in the logs on my system is that in both < and > cases, &lt; and &gt; are sent to the synth. Only the former case seems to be posing problem, speech-dispatcher's ibmtts.c (used for the sd_voxin module shipped by speechd) is stuck in the eciAddText call, so it cannot do better here...

joanmarie commented

Makes sense, but any guesses as to why it's only a problem now? It was reported on the Orca list, and I'm rather surprised that we're only just now hitting it....

joanmarie commented

For completeness, here's the voxin.log from 3.3rc6.

joanmarie commented

Also for completeness, I just emailed the contact address for Oralux to report this issue. (Couldn't find an issue tracker.) I CCed @sthibaul. 🤞

sthibaul commented

Makes sense, but any guesses as to why it's only a problem now?

Some improper parsing of the &lt; entity, but I don't have any more precise idea.

It was reported on the Orca list, and I'm rather surprised that we're only just now hitting it....

It depends on the actual configuration. Actually in my setup I had to disable the symbols.dic processing, which was replacing it with an actual word.

sthibaul commented

Ah, in your setup it's actually a mere < that is sent to the synth. But that's the same behavior as I observe.

joanmarie commented

It just occurred to me that maybe the reason we're seeing it now (at least as far as Orca is concerned) is that Orca is no longer converting the symbol before it reaches speech-dispatcher. With all the other changes (new keyhandling, de-pyatspification, etc.), I had completely spaced that out.

jeremyp3 commented

for your information, I had already reported this problem to @gcasse

I received a patch from him to correct the voxin crash.
https://oralux.org/soft/tmp/3.3rc6/fix_spelling_char_lower_than.tgz

An update is now available pending a future future delivery from voxin.
This update assumes that version 3.3rc6 has already been
installed under /opt .
This quick fix will prevent voxin from looping endlessly when reading of this character.
A real fix will require more time and will be included in a future delivery of voxin.

joanmarie commented

for your information, I had already reported this problem to @gcasse

I received a patch from him to correct the voxin crash.

Good to know there's already a fix. Now we need it in a release.

jeremyp3 commented

@joanmarie I edited my comment to include the patch link, if that helps.

gcasse commented