Bugzilla Bug 163285

Hi guys,

The latest gnome-speech comes with a new driver for the light espeak engine,
which seems very promising, and could become the default driver I'll end up
using in gnome-speech's ebuild (instead of festival).

Before bringing the latest gnome-speech to portage, please test and add your
keywords to espeak-1.18 if possible. Thanks.

Target keywords:
  ~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86

All I get out of espeak on ppc is:
Bad data: '/usr/share/espeak-data/en_dict'
Any ideas?

(In reply to comment #1)
> All I get out of espeak on ppc is:
> Bad data: '/usr/share/espeak-data/en_dict'
> Any ideas?

I'm not sure if this would help, but try recompiling the dict file. Unpack the
sources, go to 'espeak-1.18-source/dictsource' and run:
   espeak --compile=en

It replaces the file under /usr/share/espeak-data, so you might have to run it
as root.

If this fixes the problem, I'll try to come up with a solution to include in
the ebuild.

> Target keywords:
>   ~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86
> 

Fails on amd64 here with the following:

dictionary.cpp: In member function 'void Translator::InitGroups()':
dictionary.cpp:222: warning: format '%x' expects type 'unsigned int', but
argument 4 has type 'long int'
dictionary.cpp: In member function 'int Translator::IsLetter(int, int)':
dictionary.cpp:595: error: cast from 'wchar_t*' to 'int' loses precision

-James

(In reply to comment #3)
> Fails on amd64 here with the following:

Coincidentally I was just testing espeak on a (remote) amd64 system, so I can't
really make sure it produces sound, but I created a patch to fix compilation
there. I committed it a few minutes ago, so please re-try in a little while.

Also, the patch doesn't tackle all 64bit related warnings, so if someone can
contribute a thorough, and correct patch for 64bit arches, it would be very
much appreciated :).

The(In reply to comment #2)
> I'm not sure if this would help, but try recompiling the dict file. Unpack the
> sources, go to 'espeak-1.18-source/dictsource' and run:
>    espeak --compile=en

That fixes the error message. It doesn't output any sound though. If I output
to a wav file and try to play the wav with aplay I get no sound, but the
following text:

$ aplay test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 576061440 Hz, Mono
aplay: set_params:961: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 16
CHANNELS: 1
RATE: NONE
PERIOD_TIME: (21333 21334)
PERIOD_SIZE: (12289118 12289119)
PERIOD_BYTES: (24578236 24578238)
PERIODS: (16 17)
BUFFER_TIME: (341333 341334)
BUFFER_SIZE: 196628971
BUFFER_BYTES: 393257942
TICK_TIME: 0

Please test again with espeak-1.19; this was just added to portage.

Thanks,

William

(In reply to comment #6)
> Please test again with espeak-1.19; this was just added to portage.
> 

Fixes my problems on AMD64 (from comment #3)!

Thanks!

-James


> Thanks,
> 
> William
> 

I'm getting a segfault on ppc64:


Thread 1 (process 25230):
#0  0x00000400003d1930 in .__libc_free () from /lib/libc.so.6
No symbol table info available.
#1  0x00000400003d3974 in .malloc () from /lib/libc.so.6
No symbol table info available.
#2  0x00000400001d2468 in Alloc (size=74236) at speak_lib.cpp:241
        p = 0x121fc <Address 0x121fc out of bounds>
#3  0x00000400001dbd58 in Translator::LoadDictionary (this=0x10021840,
name=0xfffffd82500 "en", no_error=0)
    at dictionary.cpp:153
{....}



If I make this change it does not segfault any more (please note that this is
just a guess for a fix):

##############################################################################
--- espeak-1.19-source/src/speak_lib.cpp.orig   2007-02-01 19:34:01.360979913
+0000
+++ espeak-1.19-source/src/speak_lib.cpp        2007-02-01 19:34:13.708979913
+0000
@@ -238,7 +238,7 @@
 char *Alloc(int size)
 {//==================
   char *p;
-  if((p = (char *)malloc(size)) == NULL)
+  if((p = (char *)malloc(size+1)) == NULL)
     fprintf(stderr,"Can't allocate memory\n");
   return(p);
 }
##############################################################################


unfortunately I'm getting the error from comment #1 now:

$ espeak "Hello"
Bad data: '/usr/share/espeak-data/en_dict'

It appears that big endian systems like ppc and sparc will need some extra
lovin' in the ebuild.


From the ReadMe from espeak:

PowerPC and Big-Endian Processors
=================================

The compiled data in the espeak-data directory is not binary compatible between
processors with different byte ordering.  For a PowerPC or other big-endian
processor use must use data which has been compiled (using espeakedit) on
a big-endian processor.

(In reply to comment #9)
> It appears that big endian systems like ppc and sparc will need some extra
> lovin' in the ebuild.

Yes, the *_dict and phon* files in /usr/share/espeak-data are binaries made in
a little-endian system. Unfortunately, the only way at the moment to compile
the phon files is using espeakedit, an additional tool that requires wxwidgets.

However, discussing with one of the upstream developers, there are a couple of
alternatives. One would be to use data files from binary packages made by other
distributions for big-endian architectures. The other one which I've been
working on lately is to use a conversion tool to adjust the binaries according
to the byte order of the host.

For big-endian arch teams, please try the following and let us know the
results:

1) Emerge espeak with "-DARCH_BIG" in your CXXFLAGS. For instance:

  CXXFLAGS="-O2 -DARCH_BIG" emerge espeak

2) Download and uncompress the following:

  http://dev.gentoo.org/~leonardop/espeak/espeak-utils-1.19.tar.bz2

Compile the tools with 'make'. Then run './espeak-phoneme-data'. Then (as
root):

  cp phondata phonindex phontab /usr/share/espeak-data

3) Compile the dict files as described in comment #2. That is, uncompress the
espeak sources, then from the 'speak-1.18-source/dictsource' directory, run (as
root):

  espeak --compile=en

to compile the english dict.

---
These steps are not yet included in the ebuild while we make sure this approach
works, but of course the idea is to make this all work transparently.

If you have any further questions, try to find me on IRC. I figure it would be
faster to debug this there than using bugzilla mails if necessary :).

Thanks for all the testing.

(In reply to comment #10)
> (In reply to comment #9)
> > It appears that big endian systems like ppc and sparc will need some extra
> > lovin' in the ebuild.
> Yes, the *_dict and phon* files in /usr/share/espeak-data are binaries made in
> a little-endian system. Unfortunately, the only way at the moment to compile
> the phon files is using espeakedit, an additional tool that requires wxwidgets.
> However, discussing with one of the upstream developers, there are a couple of
> alternatives. One would be to use data files from binary packages made by other
> distributions for big-endian architectures. The other one which I've been
> working on lately is to use a conversion tool to adjust the binaries according
> to the byte order of the host.
> For big-endian arch teams, please try the following and let us know the
> results:
> 1) Emerge espeak with "-DARCH_BIG" in your CXXFLAGS. For instance:
>   CXXFLAGS="-O2 -DARCH_BIG" emerge espeak

In looking at the makefile further, I see that this is taken care of for the
ppc architecture using 'uname -m'.  What other big-endian procescors are there?
 If someone can give me the output for 'uname -m' for these processors, I will
write a patch for the makefile that does this automatically.

I have added the patch from comment #9.

Also, I added a patch which removes -dARCH_BIG from CXXFLAGS.

Big-Endian arch teams:  Everything in comment #10 still applies except for step
1, so please test and let us know the results.

Everyone else, please re-emerge espeak-1.19 also and let us know the results.

(In reply to comment #12)

> Everyone else, please re-emerge espeak-1.19 also and let us know the results.
> 

Works for me still

-James

amd64 stable

(In reply to comment #11)
>  If someone can give me the output for 'uname -m' for these processors, I will
> write a patch for the makefile that does this automatically.

hppa has:

elmer ~ # uname -m
parisc

Wouldn't patching configure more elegantly take care of this? Should not be
difficult to make it check endianness (instead of some fixed list of
architectures).

(In reply to comment #15)
> (In reply to comment #11)
> >  If someone can give me the output for 'uname -m' for these processors, I will
> > write a patch for the makefile that does this automatically.
> hppa has:
> elmer ~ # uname -m
> parisc
> Wouldn't patching configure more elegantly take care of this? Should not be
> difficult to make it check endianness (instead of some fixed list of
> architectures).

Actually, this has been taken care of by patching the source -- take a look at
the espeak-1.20-big-endian.patch.

(In reply to comment #16)
> Actually, this has been taken care of by patching the source -- take a look at
> the espeak-1.20-big-endian.patch.

I did that, then I wrote the above. Actually, that patch appears to resolve the
entirely different issue of compiling something that ought to work on bigendian
systems, not the problem of recompiling these dictionaries when necessary,
something that apparently needs to be done in pkg_post_install. As it is now,
espeak builds on HPPA, suffers the "Bad data" problem, which is seemingly fixed
by doing what comment #2 says, but still fails in generating pretty sounds. For
instance, for espeak-1.19-source/dictsource/ReadMe a 24MB WAV file of more than
9 minutes of absolute silence (in mono) was generated:

# espeak -f espeak-1.19-source/dictsource/ReadMe -w test.wav

I will see if espeak plays dumb on an x86 as well. :)

(In reply to comment #17)
> As it is now,
> espeak builds on HPPA, suffers the "Bad data" problem

Please see the instructions on comment #10. We're still waiting for some input
from someone who can test that, so we can finally implement a solution directly
in the ebuild.

By the way, the espeak-utils tarball I mention on that comment works with
espeak-1.19, I'll create a new one for 1.20 and put it in the same directory
shortly. Just make sure you use the same version of espeak and espeak-utils
when testing.

Thanks.

espeak-1.19 on ppc, using the process described in comment #10, works.  I get
the following warning:

# espeak --compile=en
Bad data: '/usr/share/espeak-data/en_dict'
Bad data: '/usr/share/espeak-data/en_dict'
Using phonemetable: 'en'
Compiling: 'en_list'
        2393 entries
Compiling: 'en_rules'
        4787 rules, 95 groups

However, reading from a simple text file and outputting to a wav file produces
a n actually audio recording of the text; very cool.  So I guess whenever the
ebuild gets fixed to remove the manual step, this should be ready for a ~ppc
keyword.

Thanks for the note Nathan.

Okay, so now there's an ebuild for espeak-1.22, and it includes all the magic
that should make it work on big-endian machines. I extend my invitation to the
arch teams to give this a try again.. :)

Thank you.

~sparc'd.
There seems to be some versioning issues involved, i get a warning "Wrong
version of espeak-data 0x1220100 (expects 0x12201)" when running espeak,
however it works fine.

(In reply to comment #21)
> There seems to be some versioning issues involved, i get a warning "Wrong
> version of espeak-data 0x1220100 (expects 0x12201)" when running espeak,
> however it works fine.

Same on HPPA.

Output to a WAV file is usable. However, espeak only produces white noise on
the sound system, which basically makes it unusable as it is now. I haven't yet
figured out if espeak or portaudio is to blame.

Added ~ppc

All,

I just did a version bump for espeak 1.25, which includes the utilities to
convert the phoneme data to big-endian if necessary.

Please see if this works on the following arches and add the appropriate
keywords:

Target keywords:
  ~alpha ~hppa ~ia64 ~ppc64

Thanks much.

Does anyonne have any updates on this?

Thanks much.

Can't do it on alpha or ia64, nobody has soundcard.

(In reply to comment #24)
> All,
> 
> I just did a version bump for espeak 1.25, which includes the utilities to
> convert the phoneme data to big-endian if necessary.

I get the exact same results with app-accessibility/espeak-1.25: it writes good
WAV files, but its output directly to a sound device is just white noise,
probably due to endianness. That means its most useful function in terms of
accessibility is still not portable. This ought to be fixed before espeak goes
stable on HPPA, which in all likelihood means it needs a decent patch (from us)
or a new version (from upstream).

That said, it does partly work properly so it deserves a keyword now. Marked
~hppa.

(In reply to comment #26)
> Can't do it on alpha or ia64, nobody has soundcard.
> 

Just installed an AU8810 card into my alpha.

Testing =app-accessibility/espeak-1.25

1. Compiles fine
2. Passes Collision-test
3. Works great tested with different options including languages

# emerge --info
Portage 2.1.2.7 (default-linux/alpha/2007.0, gcc-4.1.2, glibc-2.5-r2,
2.6.21-gentoo-r1 alpha)
=================================================================
System uname: 2.6.21-gentoo-r1 alpha EV56
Gentoo Base System release 1.12.9
Timestamp of tree: Wed, 06 Jun 2007 21:20:01 +0000
distcc 2.18.3 alpha-unknown-linux-gnu (protocols 1 and 2) (default port 3632)
[enabled]
ccache version 2.4 [enabled]
dev-lang/python:     2.4.4-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r7
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17.50.0.16
sys-devel/gcc-config: 1.3.15-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="alpha"
AUTOCLEAN="yes"
CBUILD="alpha-unknown-linux-gnu"
CFLAGS="-mieee -pipe -O2 -mcpu=ev56"
CHOST="alpha-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash
/etc/terminfo"
CXXFLAGS="-mieee -pipe -O2 -mcpu=ev56"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache collision-protect distcc distlocks metadata-transfer
parallel-fetch sandbox sfperms strict test"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="en"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/overlay"
SYNC="rsync://eldest/gentoo-portage"
USE="X acl alpha alsa berkdb bitmap-fonts bzip2 cli cracklib crypt cups curl
dri fortran gdbm gpm iconv ipv6 isdnlog ldap libg++ logrotate midi mudflap
ncurses nls nptl nptlonly openmp pam pcre perl postfix pppd python readline
reflection session spl sqlite ssl startup-notification tcpd test truetype-fonts
type1-fonts unicode xorg zlib" ALSA_CARDS="cs46xx au8810"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="vga s3virge nv"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Alpha done. Thanks Brian.

- ferdy

All,

espeak  1.26 has been released, and we still need ~ia64 and ~ppc64.

Does anyone on the ia64 team have any suggestions regarding how we can get
~ia64 added to this?

ppc64 team, can you please test and add your keyword to this package?

Thanks much.

Created an attachment (id=121623) [details]
Fixing byte order of phoneme data files fails on ppc64

sorry, no ~ppc64 keyword. I'm still getting the segfault from comment #8 and
now the byte order of the phoneme data files cannot be fixed, too.

Can't do it on ia64, i don't have a local box and nobody has a local box +
soundcard. And we're only two persons.

Jeroen Roovers: Thanks for adding the patch for ppc64 from comment #8. Please
note, that the patch might not be the correct fix and I just tried this and
that until the segfaults stopped ;-)
Unfortunately I'm still getting those "free(): invalid next size (normal)",
while compiling the speech data and so cannot run "espeak":

# espeak 
Wrong version of espeak-data 0x1260100 (expects 0x12601)
Bad data: '/usr/share/espeak-data/en_dict'
Bad data: '/usr/share/espeak-data/en_dict'

All,

I have added espeak 1.28 to the tree, but without the patch from comment #8.

I have emailed the patch to upstream, and we have been asked if we can assist
him in finding out which call to Alloc() is causing the issue.

What we need to do is, in turn, add 1 to the size parameter for each call to
Alloc() in the code until the segfaults stop.

ppc64 team, can you do this and let me know which call to Alloc() is the issue
so I can relay that to upstream?

Your help would be appreciated very much.

I'm currently busy with university, but starting in august I should have some
spare time.

regards,

-corsair

All,

espeak 1.29 is in the tree.

ppc64 team,

Can you please check this one out and see if it still segfaults?  If so, can
you assist me with providing information about which call causes the problem?

Thanks much,

William

ppc64 team,

what is the status of this bug?

Thanks much,

William

(In reply to comment #37)
> what is the status of this bug?

it's not working.

would access to a dev ppc64 box help resolve this?

Now we are up to 1.31.  Can someone take a look at this and follow up on
comment #34?


Thanks,

William

Remote access to a box probably would not work for this since this application
is a speech synthesizer.  

Hi,
I had also had issues with espeak-1.31 on a big-endian platform (ARM).
Eventually I found a few problems in the code regarding endianess as well as
64-bit architectures.
The attached patch tries to fix both, however I could not test on a 64-bit
architecture. It is still necessary to convert the phon* files but there is no
need to recompile the dictionaries! The patch also includes a fix from upstream
(phonemelist.cpp 135->147) with caused seg-faults.
Please check it out to see if it improves things on ppc64.
-Thomas


PS: Remote access to a ppc64 box should give you at least the ability to create
wav-files and see if they contain what you expect.

Created an attachment (id=145017) [details]
Patch for endianess and 64-bit issues

Patch against espeak-1.31.
Tested on a big-endian 32-bit machine, not tested on 64-bit architectures yet.

Ok, my previous patch was a bit over the top - just learned that 64-bit systems
are not that different. Anyway, the fixed patch is attached, please check it
out. Only the phon* files need convertion, no need to recompile the dict files.
-Thomas

Created an attachment (id=145136) [details]
Smaller patch replacing the previouse one!

Now there is espeak 1.34 available which does not need any recompiling of dict
files for big-endian systems. Only the endianess of phon* files has to be
swapped using the included tool.
Can you still observe the Alloc issue?

Created an attachment (id=145499) [details]
ebuild for 1.34

I just committed 1.34 to the tree.

Thanks for letting me know about it.

added ~ppc64.

1.34 finally works on ppc64. malloc patch not needed.

For me the committed version does not work, i.e. audio can only be written to a
file but output via portaudio is not compiled in. The command lines for
compiling look like:

g++ -O2 -march=nocona -pipe -D PATH_ESPEAK_DATA=\"//usr/share/espeak-data\"
-Wall -pedantic -I. -c -fno-exceptions  speak.cpp

There is no "-DUSE_PORTAUDIO" which is computed in the Makefile and assigned to
CXXFLAGS. However I think the build environment's CXXFLAGS overrides that
variable thus dropping the neccessary define.
In my attached ebuild I suggested adding this define to the make call:
  emake CXXFLAGS="${CXXFLAGS} -DUSE_PORTAUDIO"
which works for me.

Do others see the same problem?
-Thomas

Thomas,

I just committed a new ebuild for version 1.35, which was just released.
Please update again and let me know if your issue is fixed.

Thanks.

William

Yes, the 1.35 version works very well (I just checked with portaudio though).
Thanks!

IA64 team,

What is your status on this, can someone take a look at keywording espeak-1.35?

Thanks much,

William

Hi,

~x86 espeak 1.36   USE="portaudio pulseaudio"

When I use     # espeak "hello"     I can't hear anything,
But    # espeak -w 1.wav "hello"     makes a wave file that works!
I try   # espeak --compile=en     it says:  Can't access (r) file 'en_rules'

In reply to comment #54:

This would be a separate issue, and not related to this keyword request.
Please file it as a separate bug.

Thanks,

William

Added ~ia64, closing. Looks like it made a correct wav file, just that i didn't
play it correctly :P Sorry for the wait