Did you rebuild entire project or recompiled phoneme tables before tests?

Hi, I'm not totally sure if it's a bug or not, but it's a bit obscure to me. Here is my use case.

For transcription purpose, I'd like to rewrite my own phoneme tables for english, and I've stumbled on the following oddity.

I keep the original en_rules and en_dict files, but I'm rewriting a new english voice, called en-test (file espeak-ng-data/lang/gmw/en-test), with the following content :

name Test English
language en-test  42
language en 42
phonemes en-test
tunes s1 c1 q1 e1

I'm declaring the new phoneme table like this (in the phonemes file) :

file : phonemes

phonemetable en-test base1
include ph_english_test

Note that it does not inherit from the en table, but directly from base1.

Finally, I'm declaring the ph_english_test phoneme file (in phsource/ph_english_test). It's really simple, with only one phoneme (I've reduced the example to a minimal test case to illustrate my problem) :

file : phsource/ph_english_test

phoneme a#
  vwl
  ipa £
endphoneme

Now, if I try to translate the following example, the a# phoneme is not used :

> espeak-ng against -v en-test -X --ipa
Found: 'against' [a#gEnst]
əɡˈənst

The strange thing is, if I add the phoneme to base1 in the phonemes file, like this (note the different ipa character) :

file : phonemes

phoneme a#
  vwl
  ipa $
endphoneme

then the phoneme is used, and it is taken from the child table :

> espeak-ng against -v en-test -X --ipa
Found: 'against' [a#gEnst]
ˈ£ɡənst

Finally, if I remove the a# phoneme from the child table, then the phoneme is still found and used, and it comes from base1, the parent table :

> espeak-ng against -v en-test -X --ipa
Found: 'against' [a#gEnst]
ˈ$ɡənst

To summarize, here are the four possible cases for the parent and child tables :

Parent : not defined, Child : not defined => Not translated (pretty logical) Parent : defined, Child : defined => translated, uses child table definition (pretty logical) Parent : defined, Child : not defined => translated, uses parent table definition (pretty logical) Parent : not defined, Child : defined => Not translated (seems odd)

Is this behavior really normal? I would have expect the a# phoneme to be working without having to define it in the parent table, just in the child table. Is there something I'm doing wrong or is it a bug?

After building from source and installing eSpeak on Windows10, there is no voices showing up on the Speech Synthesizer personnalisation . How can I fix this?

grep -E is the same as egrep in Linux. What about MacOS?

[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By BenTalagan:

Under MacOS, it seems egrep and grep are the same binary.

➜  espeak-ng git:(master) egrep --version
egrep (BSD grep) 2.5.1-FreeBSD
➜  espeak-ng git:(master) grep --version
grep (BSD grep) 2.5.1-FreeBSD
➜  espeak-ng git:(master) ls -lat /usr/bin/egrep
-rwxr-xr-x  1 root  wheel  47136 24 oct 03:33 /usr/bin/egrep
➜  espeak-ng git:(master) ls -lat /usr/bin/grep 
-rwxr-xr-x  1 root  wheel  47136 24 oct 03:33 /usr/bin/grep
➜  espeak-ng git:(master) md5sum /usr/bin/egrep 
fa0d64532039165615fb06d6143076d9  /usr/bin/egrep
➜  espeak-ng git:(master) md5sum /usr/bin/grep 
fa0d64532039165615fb06d6143076d9  /usr/bin/grep

[espeak-ng:master] By BenTalagan <ben_talagan@...>:
c7827df43b16: Using grep -E on all platforms

Modified: tests/language-replace.test

[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By rhdunn:

I've merged this commit by cherry-picking the last commit. Thanks for the fix.

[espeak-ng/espeak-ng] Pull request closed by rhdunn:

#677 Fixing "Language Replace" tests under MacOS

A small PR for fixing the language-replace.test script under MacOS. The grep -P is unfortunately not portable, but in that simple case the grep -E option will do. Any other suggestion is welcome :-)

[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By BenTalagan:

Ok! Thanks a lot.

Why not replace it directly with -E, as that is supported in GNU grep?

[espeak-ng/espeak-ng] Pull request updated by BenTalagan:

#677 Fixing "Language Replace" tests under MacOS

A small PR for fixing the language-replace.test script under MacOS. The grep -P is unfortunately not portable, but in that simple case the grep -E option will do. Any other suggestion is welcome :-)

[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By BenTalagan:

Good point! I wasn't sure. I have done the change, just waiting for the tests to be over.

[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By BenTalagan:

Good point! I wasn't sure. I have made the change, just waiting for the tests to be over... done.

#677 Fixing "Language Replace" tests under MacOS

A small PR for fixing the language-replace.test script under MacOS. The grep -P is unfortunately not portable, but in that simple case the grep -E option will do. Any other suggestion is welcome :-)

[espeak-ng/espeak-ng] Pull request updated by BenTalagan:

#677 Fixing "Language Replace" tests under MacOS

A small PR for fixing the language-replace.test script under MacOS. The grep -P is unfortunately not portable, but in that simple case the grep -E option will do. Any other suggestion is welcome :-)

[espeak-ng/espeak-ng] Pull request updated by BenTalagan:

#677 Fixing "Language Replace" tests under MacOS

A small PR for fixing the language-replace.test script under MacOS. The grep -P is unfortunately not portable, but in that simple case the grep -E option will do. Any other suggestion is welcome :-)

[espeak-ng:master] Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation closed by BenTalagan.

[espeak-ng:master] By BenTalagan <ben_talagan@...>:
94677f4af8ad: Rule alignment fixes for non compliant platforms / Fix for emscripten demo

Modified: emscripten/Makefile
Modified: emscripten/post.js
Modified: src/libespeak-ng/dictionary.c
Modified: src/libespeak-ng/readclause.c
Modified: src/libespeak-ng/readclause.h
Modified: src/libespeak-ng/translate.c

[espeak-ng:master] By BenTalagan <ben_talagan@...>:
9fd480afbf4f: Fixing typos and naming

Modified: src/libespeak-ng/dictionary.c
Modified: src/libespeak-ng/readclause.c
Modified: src/libespeak-ng/readclause.h
Modified: src/libespeak-ng/translate.c

[espeak-ng:master] By BenTalagan <ben_talagan@...>:
02447abde8b3: Fixing is_str_totally_null

Modified: src/libespeak-ng/readclause.c

[espeak-ng:master] By Reece H. Dunn <msclrhd@...>:
050d5e498261: Merge remote-tracking branch 'BenTalagan/master'

Modified: emscripten/Makefile
Modified: emscripten/post.js
Modified: src/libespeak-ng/dictionary.c
Modified: src/libespeak-ng/readclause.c
Modified: src/libespeak-ng/readclause.h
Modified: src/libespeak-ng/translate.c

[espeak-ng/espeak-ng] Pull request closed by rhdunn:

#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo

This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided.

Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.

[espeak-ng:master] New Comment on Pull Request #676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo
By rhdunn:

That's what tests are for :).

Thanks for the fix.

Pheew! I really need some rest, you saved me from pushing some really silly code. Looks better now.

They are passing on the master branch. The failing test is https://travis-ci.org/espeak-ng/espeak-ng/jobs/613903437#L2232.

#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo

This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided.

Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.

Hum, checks failed, but I've verified locally and it looks like that they were already broken before these changes. Is it normal?

#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo

This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided.

Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.

[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By BenTalagan:

@rhdunn : Thanks for your answer ! I have prepared a PR (#676), and limited myself to add a function to test sequential bytes to zero. It's very close to what was intended originally and non intrusive (the original code only tests four bytes, but after that they are still read one by one, not 4 by 4).

Thanks for the analysis. It looks like a version of Read4Bytes (https://github.com/espeak-ng/espeak-ng/blob/master/src/libespeak-ng/readclause.c#L280) for a const char * is needed to fix this -- renaming Read4Bytes to fread_uint32 and create a read_uint32 function. The code would then need to be audited to avoid direct casting to unsigned int *.

Ok, after fixing the condition in FindReplacementChars, it seems I can get back a working generation/transcription with emscripten. I'd still need some expertise to tell me if I'm missing some potential similar alignment problems.

After implementing a temp fix :

while (p[0] != 0 && p[1] != 0 && p[2] != 0 && p[3] != 0) {
				p++;
			}

the parsing of the rules looks ok now, but the translation is still messed up. Found at least one suspicious place (within commit 55c6403) :

https://github.com/espeak-ng/espeak-ng/blob/48719ad642f8a27d352983ab5964463a8c1e033e/src/libespeak-ng/translate.c#L1793-L1799

After taking time to investigate, I think I have found the problem. It comes from the following lines :

https://github.com/espeak-ng/espeak-ng/blob/48719ad642f8a27d352983ab5964463a8c1e033e/src/libespeak-ng/dictionary.c#L153-L154

They behave differently when compiled with llvm and emscripten. Under llvm, like with gcc, this will have what I would call an 'expected' behaviour : the cast to unsigned int from any position in the char* buffer will take into account the fact that we are not aligned to a multiple of 4 bytes. Under emscripten it doesn't : shifting by n+0, n+1, n+2 or n+3 bytes leads indifferently to the same result when casting to an int. One of the rules of the 'en' dictionary falls under this case, so the condition of having 4 successive bytes at 0 is not met and the rule parser explodes.

@rhdunn, I'd like your opinion on that issue : should we implement a simple fix for this (like testing the four bytes instead of casting to unsigned int), are there any other part of the code that may be concerned?

[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By BenTalagan:

After taking some time to investigate, I think I have found the problem. It comes from the following lines :

https://github.com/espeak-ng/espeak-ng/blob/48719ad642f8a27d352983ab5964463a8c1e033e/src/libespeak-ng/dictionary.c#L153-L154

They behave differently when compiled with llvm and emscripten. Under llvm, like with gcc, this will have what I would call an 'expected' behaviour : the cast to unsigned int from any position in the char* buffer will take into account the fact that we are not aligned to a multiple of 4 bytes. Under emscripten it doesn't : shifting by n+0, n+1, n+2 or n+3 bytes leads indifferently to the same result when casting to an int. One of the rules of the 'en' dictionary falls under this case, so the condition of having 4 successive bytes at 0 is not met and the rule parser explodes.

@rhdunn, I'd like your opinion on that issue : should we implement a simple fix for this (like testing the four bytes instead of casting to unsigned int), are there any other part of the code that may be concerned?

[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By BenTalagan:

Add : after reading a bit on the net, it really looks like this should be rewritten. Some refs :

https://stackoverflow.com/questions/26995151/how-to-cast-char-array-to-int-at-non-aligned-position

https://stackoverflow.com/questions/13881487/should-i-worry-about-the-alignment-during-pointer-casting

[espeak-ng:master] By BenTalagan <ben_talagan@...>:
3e0150a34fd4: Fixing ungetc bad behavior under macOS Catalina by avoiding to ungetc a different char from the last getc

Modified: src/libespeak-ng/compiledata.c

[espeak-ng:master] By Reece H. Dunn <msclrhd@...>:
48719ad642f8: Merge remote-tracking branch 'BenTalagan/master'

Modified: src/libespeak-ng/compiledata.c

[espeak-ng/espeak-ng] Pull request closed by rhdunn:

#675 Fixing ungetc bad behavior under macOS Catalina

This is a fix for (#674). For archiving purpose, the problem was the following : it seems that the ungetc implementation under Catalina has interferences with ftell/fseek when ungetc pushes back a character which is different from the one that is preceding the current file pointer.

The fix consists in avoiding such a situation.

[espeak-ng:master] New Comment on Pull Request #675 Fixing ungetc bad behavior under macOS Catalina
By rhdunn:

Merged. Thanks.

[espeak-ng:master] Label added to issue #674 Build fails on MacOS Catalina by BenTalagan.

[espeak-ng:master] Issue #674 Build fails on MacOS Catalina closed by BenTalagan.