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 attachment 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 attachment 145017 [details, diff] 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 attachment 145136 [details, diff] 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 attachment 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
