Re: Bug#706902: bugs.debian.org: Adding an a11y tag?

2017-06-27 Thread Reece Dunn 
On 27 June 2017 at 17:16, Samuel Thibault  wrote:

> Alex ARNAUD, on mar. 27 juin 2017 17:44:51 +0200, wrote:
> > Le 27/06/2017 à 16:36, Don Armstrong a écrit :
> > > On Tue, 27 Jun 2017, Samuel Thibault wrote:
> > > > Don Armstrong, on lun. 26 juin 2017 19:26:33 -0700, wrote:
> > > > > Its one-letter symbol is ⓐ.
> > > >
> > > > Ah, I hadn't thought about it. I guess it would make sense that it
> be ♿?
> > >
> > > I wasn't in the best position to know if the ISA (♿) was the right
> > > symbol (because accessibility means more than mobility accessibility
> and
> > > other questions[1]),
>
> > For example my speech synthesis (espeak) doesn't
> > read the one-letter tag.
>
> I'd say it's a bug that should be reported to the speech synthesis.
> Ideally it should be able to pronounce all of Unicode. At least the
> common symbols should be pronounceable.
>
> Does it speak the wheelchair ? (♿)
>

The latest development version of espeak-ng has support for Unicode Emoji
5.0, so will read the character as "wheelchair symbol" (or the appropriate
phrase in the CLDR translations of that symbol for the given language).

The more complex emoji sequences (e.g. the skintone indicators) are only
partially supported. Complete support requires changes to the text
processing code, which is complicated and that I am planning for the
release after the current version in development.

As a temporary workaround, you can add:

♿w'i:ltSe@||s'Imb@L

to either en_list or en_extra, as the en_emoji file in the development
version is not compatible with 1.49.1 (it uses "♿wheelchair symbol").

Kind regards,
Reece

Re: orca on debian stretch testing

2017-01-06 Thread Reece Dunn 
On 6 January 2017 at 08:20, Sebastian Humenda  wrote:

> Hi
>
> Samuel Thibault schrieb am 06.01.2017,  0:45 +0100:
> >Sebastian Humenda, on Thu 05 Jan 2017 20:56:20 +0100, wrote:
> >> >I just installed Debian testing using the net installation iso for the
> >> >week of November 28th, 2016 and the only major issues I found is that
> if you
> >> >press a key espeakup lags around a little behind of when you press the
> key.
> >> Thanks for testing. This should be better with the next installer
> version, this
> >> issue has been fixed.
> >
> >Has it?  In Bug#848016, Eric Scheibler reports that he still notices
> >delay with version 1.49.0+dfsg-3 of libespeak-ng1, and I'm unfortunately
> >considering reverting to espeak for Stretch.
> Apologies! I mixed that up -- this issue was fixed upstream, I believe.
> I have seen a commit message promising that.
>

Have you tried the upstream version of espeak-ng, or just going on the
commit messages?

I made changes that make improvements to the current situation on my test
setup. I will do more testing to see what I can do.

The change I told Samuel about should have had the same effect. The other
changes that I made that could affect this are (in order) the commits
a48576a3640f9014760888bb30a924a3e2163e57,
bc674081cd0e787e364989baab82df0ce883abec and
d2478cc453750e4081e0b6eaeca1442b8abaa92f.


> Yes, I think reverting back to espeak sounds sensible.
>

That would be my recommendation for brltty on stretch if the above does not
help. When espeak-ng works better with brltty, it could be considered
post-stretch.

Kind regards,
Reece


> Sebastian
> --
> Web: http://www.crustulus.de (English|Deutsch)  | Blog:
> http://www.crustulus.de/blog
> FreeDict: Free multilingual dictionaries - http://www.freedict.org
> Freies Latein-Deutsch-Wörterbuch: http://www.crustulus.de/freedict.de.html
>

Re: espeak-ng fork of espeak

2016-09-11 Thread Reece Dunn 
On 11 September 2016 at 11:30, Samuel Thibault  wrote:

> Hello,
>
> Reece Dunn, on Sun 11 Sep 2016 08:42:21 +0100, wrote:
> > ieee80.c is present in other applications and libraries with similar
> headers:
> >
> > 1.  wxWidgets (extended.c) -- [3]https://github.com/
> wxWidgets/wxWidgets/blob/
> > master/src/common/extended.c#L20
> > 2.  sox (aiff.c) -- [4]https://searchcode.com/
> codesearch/view/18633063/#l-1043
> > 3.  nyquist (ieeecvt.c) -- [5]https://github.com/
> vijayrudraraju/nyquist/blob/
> > master/snd/ieeecvt.c
> > 4.  speech-tools (EST_wave_utils.cc) -- [6]http://www.festvox.org/docs/
> > speech_tools-2.4.0/EST__wave__utils_8cc_source.html#l00626
>
> Well, that doesn't make it a piece of free software, and Debians'
> ftpmaster may not buy that argument, since all these projects may have
> just been sloppy and just copy/pasted the code without caring about the
> only line of useful copyright information:
>
>  * Copyright (C) 1988-1991 Apple Computer, Inc.
>  * All rights reserved.
>
> which basically means non-free... I can understand that perhaps the
> source has been freed at some point, but there is no notice to back
> that.
>
> Looking a bit more, I have found this:
>
> http://www.realitypixels.com/turk/opensource/ToFromIEEE.c.txt
> (linked from http://www.realitypixels.com/turk/opensource/index.html)
>
> That file will be bought by ftp-master :)
>

Thanks. I will use that version in espeak-ng (commenting out the TEST_FP
define to make it useable within espeak-ng).


> > | Also, release tarballs usually contain ./configure etc., i.e.
> > | autoreconf -i was run before making the tarball, so the user can just
> > | ./configure && make && sudo make install
> >
> > I have included the `autogen.sh` script to generate those files (as used
> by
> > wayland and various other projects). Thus:
> >
> > ./autogen.sh && ./configure && make && sudo make install
> >
> > I could generate the configure scripts, etc. but they are tied to the
> version I
> > generate them with (e.g. generating the tarball on testing will make them
> > incompatible with stable and wheezy).
>
> ?!
>
> That's the contrary.
>
> Not providing the generated ./configure file means that people that want
> to build on an oldie system will *have* to use autoconf/automake at
> least recent enough for your autoconf.ac file and Makefile.am file to
> work: AC_PREREQ([2.63]) means they *have* to have at least autoconf
> 2.63 for instance. If they don't have it, they're screwed.
>

Ok. I will generate a tarball with a generated configure script.


> > | Also, are the generated voice files architecture-dependent?  In espeak,
> > | there used to be a difference between little-endian and big-endian
> > | architectures.
> >
> > Yes they are.
>
> Ok, so they should not be put in $datadir, but in $libdir, since
> $datadir is supposed to only contain arch-independent files.


I will do.

I'll create a 1.49.1 release later this week with these fixes incorporated.

Thanks for the feedback,
Reece

Re: espeak-ng fork of espeak

2016-09-11 Thread Reece Dunn 
On 11 September 2016 at 01:24, Samuel Thibault  wrote:

> Hello,
>
> Reece Dunn, on Sat 10 Sep 2016 11:35:40 +0100, wrote:
> > I have created a 1.49.0 stable release of the current codebase, as well
> as a
> > 1.0 release of the dependant pcaudiolib project ([2]https://github.com/
> > espeak-ng/pcaudiolib).
>
> Thanks!
>
> I'm having an issue, though: ieee80.c doesn't seem to have a free
> software licence.
>

ieee80.c is present in other applications and libraries with similar
headers:

1.  wxWidgets (extended.c) --
https://github.com/wxWidgets/wxWidgets/blob/master/src/common/extended.c#L20
2.  sox (aiff.c) -- https://searchcode.com/codesearch/view/18633063/#l-1043
3.  nyquist (ieeecvt.c) --
https://github.com/vijayrudraraju/nyquist/blob/master/snd/ieeecvt.c
4.  speech-tools (EST_wave_utils.cc) --
http://www.festvox.org/docs/speech_tools-2.4.0/EST__wave__utils_8cc_source.html#l00626

| Also, release tarballs usually contain ./configure etc., i.e.
| autoreconf -i was run before making the tarball, so the user can just
| ./configure && make && sudo make install

I have included the `autogen.sh` script to generate those files (as used by
wayland and various other projects). Thus:

./autogen.sh && ./configure && make && sudo make install

I could generate the configure scripts, etc. but they are tied to the
version I generate them with (e.g. generating the tarball on testing will
make them incompatible with stable and wheezy).

| Also, are the generated voice files architecture-dependent?  In espeak,
| there used to be a difference between little-endian and big-endian
| architectures.

Yes they are. That should only matter if building the voice files on one
architecture for a different architecture. Thus, you need to build the
espeak-ng-data for each architecture on that architecture.

Let me know if there are problems and I can fix them.

Kind regards,
Reece

Re: espeak-ng fork of espeak

2016-09-10 Thread Reece Dunn 
On 5 September 2016 at 22:02, Samuel Thibault  wrote:

> Hello,
>
> I'm having a look at using espeak-ng instead of espeak in Debian, but I
> couldn't find a release for it.  Is the last version in git supposed to
> stable?  We don't usually take a random git snapshot of packages :)
>

Hi Samuel,

I have created a 1.49.0 stable release of the current codebase, as well as
a 1.0 release of the dependant pcaudiolib project (
https://github.com/espeak-ng/pcaudiolib).

The headers and voice data have been moved to avoid file conflicts with the
espeak upstream versions (allowing both espeak and espeak-ng to be
installed on a system).

eSpeak NG is still ABI and API compatible with eSpeak, and can read the
eSpeak voice data.

NOTE: The voice data is now buildable from the command line without the
wxWidgets dependency. This is all done in an autotools-based build system.
Editing the voice data (i.e. an espeakedit GUI equivalent) is not currently
supported, so the espeak version of espeakedit would be needed in that case.

Kind regards,
Reece

Re: you really do not want to upgrade to alsa-lib 1.1.2 (fwd)

2016-08-09 Thread Reece Dunn 
On 9 August 2016 at 16:35, Jude DaShiell  wrote:

>
>
> --
>
>
> -- Forwarded message --
> Date: Tue, 9 Aug 2016 06:58:20
> From: Chris Brannon 
> Reply-To: Speakup is a screen review system for Linux.
> 
> To: Speakup is a screen review system for Linux. <
> spea...@linux-speakup.org>
> Subject: Re: you really do not want to upgrade to alsa-lib 1.1.2
>
> Kyle  writes:
>
> I was ready to release TalkingArch this month, just a little
>> late. Looks like I may need to hold off until next month. Is this a
>> mostly correct assessment, or is my build from Saturday OK to continue
>> the testing and sign-off process? Thanks for the heads-up.
>>
>
> I don't know which package your Saturday build contains.
> When did 1.1.2 hit [extra]?  It was probably sometime close to then.
> If you've got alsa-lib 1.1.1 or older, you should be good to go.
>
> So I've spent the best part of 3 hours tonight looking at the espeak
> source.  I'm reasonably convinced there's a race condition in the audio
> output code, even though it looks like plenty of care was taken to
> guarantee that this couldn't happen.  Or maybe I'm seeing
> things that aren't really there, and there's no race after all.
> Sometimes I feel like the most phony of amateurs.
> Anyway what I think happened is that a change to the alsa library has
> done something to trigger a race condition that has been around for a
> long time.
>

Is it possible to test if espeak-ng (https://github.com/espeak-ng/espeak-ng)
has the same issue?

The upstream version of espeak has not seen activity since 2015-04-16
(1.48.15) and has been very light on improvements to the codebase for a
long time.

The espeak-ng codebase includes many Coverity and msvc static analysis
fixes. A lot of effort has been made to clean up the codebase to make it
consistent and more readable. It is also no longer dependent on wxWidgets,
so it can be fully built from an environment that does not have an xserver
installed. A full changelog is available at
https://github.com/espeak-ng/espeak-ng/blob/master/CHANGELOG.md.

Patches are welcome for any issues, or general improvements.

Regards,
Reece H. Dunn

-- Chris
> ___
> Speakup mailing list
> spea...@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>
>

espeak-ng fork of espeak

2016-01-21 Thread Reece Dunn 
Hi,

I am the developer of a fork of the espeak project that came about due to
the extended absense of Jonathan Duddington (the author of espeak) and the
general slow pace of development on espeak. This fork is available at
https://github.com/espeak-ng/espeak-ng.

For a long time now I have been developing and maintaining an
autotools-based build system for espeak. The new espeak-ng fork builds on
this work. The key high-level changes are:

1.  Converted the sources to C99 and reformatted the codebase;
2.  Support for compiling the language and phoneme data files within the
espeak-ng program;
3.  Removed the dependency on wxWidgets;
4.  Provides man files based on the Ubuntu/Debian man files;
5.  Removed the platforms directory (portability is provided within the
main src tree, with no pre-built/external files like Microsoft's sapi.lib
being included);
6.  Major build clean up including a large number of warning and static
analysis (clang scan-build, Coverity and msvc /analyze) fixes.

While espeak-ng provides different binary names for the programs and
libraries, it also provides compatibility symlinks for applications that
look for and depend on espeak.

I am willing to incorporate patches and pull requests into the code (e.g.
if you need any changes when building it on Debian). I would also
appreciate help with static analysis issues.

Thanks,
Reece H. Dunn

Bug#750269: espeakedit: FTBFS: Makefile:19: *** recipe commences before first target

2014-06-02 Thread Reece Dunn 
On 2 June 2014 21:38, Sven Joachim  wrote:
> On 2014-06-02 22:28 +0200, Paul Gevers wrote:
>
>> On 02-06-14 22:18, David Suárez wrote:
>>> I think that the normal order of dpkg-buildpackage is to run dh_clean before
>>> patching the sources.
>
> Not in format 3.0 (quilt).
>
>> Indeed I may have been to quick to lower it, but if this problem can not
>> be fixed by a patch, how to fix it? I am going to further look it up,
>> but with source 3.0 (quilt) I believe (man dpkg-buildpackage and
>> dpkg-source) the patches are applied by dpkg-source upon unpacking.
>
> Indeed, src/Makefile is broken after unpacking (and patching), missing
> trailing backslashes in lines 18 and 20 for CPPFLAGS.

It is an upstream issue -- the problem is present in the Makefile in
the source tree (Makefile.espeakedit in svn) since it was first
introduced on 2010-06-25 (just before 1.43.48). I am not sure why it
is triggering now (make 4.0 being more strict?).

Thanks,
- Reece H. Dunn

> Cheers,
>Sven
>
>
> --
> To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/87y4xfqc6z@turtle.gmx.de
>


--
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAGdtn26OnguArFDKrw6-poFrD9=bU4w=-kjixy5thybvqbk...@mail.gmail.com

Re: Testing brltty 5.0

2014-02-28 Thread Reece Dunn 
On 28 February 2014 16:49, Sebastian Humenda  wrote:
> Hello Reece,
>
> Reece Dunn schrieb am 28.02.2014, 15:33 +:
>>On 28 February 2014 15:08, Sebastian Humenda  wrote:
>>> Mario Lang schrieb am 27.02.2014, 14:06 +0100:
>>>>brltty 5.0 in the git repo is almost ready for upload.
>>> Thanks for your work.
>>>
>>>>If you have the time, please give it a spin before we upload 5.0-1.
>>>>Here is a recipe to build brltty packages from the git repo:
>>> I've tried to build it and got:
>>>
>>> 
>>> dh_shlibdeps -a -Nbrltty-udeb
>>> dpkg-shlibdeps: error: no dependency information found for 
>>> /usr/lib/libespeak.so.1 (used by 
>>> debian/brltty-espeak/lib/brltty/libbrlttyses.so)
>>> dh_shlibdeps: dpkg-shlibdeps -Tdebian/brltty-espeak.substvars 
>>> debian/brltty-espeak/lib/brltty/libbrlttyses.so returned exit code 2
>>
>>libespeak.so.1 is installed in the multi-arch location (e.g.
>>/usr/lib/x86_64-linux-gnu) on Debian Wheezy and later.
>>
>>Do you have a custom build of espeak that has libespeak.so.1 in /usr/lib?
> Well, there was one, indeed. Thought I would have removed all remainings of
> that. Now it builds. When running however, it doesn't ommit sound with espeak
> and even with brltty -s no, it crashes after a short while.

eSpeak uses an AUDIO makefile variable to configure what sound API to use:

   runtime -- pulseaudio with portaudio fallback
   pulse -- pulseaudio only
   portaudio -- portaudio only

It uses a fixed value of 'runtime' that you need to change by hand
(e.g. a sed rule or patch file).

It may also be that the default device does not provide sound output
(e.g. on my Raspberry Pi I have a USB soundcard on sysdefault). In
this case, the application using eSpeak needs to process the audio
itself instead of delegating to eSpeak as eSpeak does not support a
custom (non-default) audio device name.

HTH,
- Reece H. Dunn

> I'll have a look whether this also happens with a «custom» build and will
> report again.
>
> Lintian reports a mass of warnings, some may be indeed a serious issue. I 
> don't
> have time yet to look into this, but I fixed this:
>
> * binary-control-field-duplicates-source
> * W: python-brlapi: maintainer-script-empty prerm (and various other packages 
> as
>   well)
>
> Sebastian
> --
> Web: http://www.crustulus.de | Blog: 
> http://www.crustulus.de/cgi-bin/blog.cgi?de-0
> Freies Latein-Deutsch-Wörterbuch: http://www.crustulus.de/freedict.de.html
> FreeDict: Free multilingual dictionary databases - http://www.freedict.org


--
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cagdtn2767a1em49j_kwuuc3f5jnhspqwfgls2f0ggqz1dbf...@mail.gmail.com

Re: Testing brltty 5.0

2014-02-28 Thread Reece Dunn 
On 28 February 2014 15:08, Sebastian Humenda  wrote:
> Hello Mario,
>
> Mario Lang schrieb am 27.02.2014, 14:06 +0100:
>>brltty 5.0 in the git repo is almost ready for upload.
> Thanks for your work.
>
>>If you have the time, please give it a spin before we upload 5.0-1.
>>Here is a recipe to build brltty packages from the git repo:
> I've tried to build it and got:
>
> 
> dh_shlibdeps -a -Nbrltty-udeb
> dpkg-shlibdeps: error: no dependency information found for 
> /usr/lib/libespeak.so.1 (used by 
> debian/brltty-espeak/lib/brltty/libbrlttyses.so)
> dh_shlibdeps: dpkg-shlibdeps -Tdebian/brltty-espeak.substvars 
> debian/brltty-espeak/lib/brltty/libbrlttyses.so returned exit code 2

libespeak.so.1 is installed in the multi-arch location (e.g.
/usr/lib/x86_64-linux-gnu) on Debian Wheezy and later.

Do you have a custom build of espeak that has libespeak.so.1 in /usr/lib?

Also, IIUC there was a bug report recently about creating a dynamic
udeb package of espeak for the installer needed by the speakup
package. This is statically linking espeak.

Maybe that is the problem?

HTH,
- Reece H. Dunn

> make: *** [brltty] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
> debuild: fatal error at line 1364:
> dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed
> gbp:error: Couldn't run 'debuild -i -I -uc -us': debuild -i -I returned 29
>
> I am not sure what exactly causes the problem.
>
> Thanks
> Sebastian
> --
> Web: http://www.crustulus.de | Blog: 
> http://www.crustulus.de/cgi-bin/blog.cgi?de-0
> Freies Latein-Deutsch-Wörterbuch: http://www.crustulus.de/freedict.de.html
> FreeDict: Free multilingual dictionary databases - http://www.freedict.org


--
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cagdtn26dxcgmkzebkzrcdjjujnhm3bygkromeh4imfcab80...@mail.gmail.com

wxWidgets 3.0 - espeakedit fixes

2013-11-15 Thread Reece Dunn 
Hi,

I have attached two patches for espeakedit:

0001-*.patch -- This makes espeakedit compile.

0002-*.patch -- This fixes a segfault when constructing the wxFont
objects for SpectFrame. These were being constructed in the global
namespace. With wxWidgets 3.0, it now requires a gtk+ window when
constructing a wxFont. The change moves creation of the fonts to the
SpectFrame constructor, so a SpectFrame object holds them internally.
I have also removed FONT_NORMAL as this was not used in the code.

These are also available on my espeak github repository at
https://github.com/rhdunn/espeak on the master branch.

NOTE: These changes should be backward compatible with wxWidgets 2.8.

Now when I try and run espeakedit I get:

-
ASSERT INFO:
../src/gtk/font.cpp(337): assert "IsOk()" failed in GetPointSize(): invalid font

BACKTRACE:
[1] wxFont::GetPointSize() const
[2] wxObject::operator=(wxObject const&) /usr/include/wx-3.0/wx/object.
h:374
[3] MyFrame::MyFrame(wxWindow*, int, wxString const&, wxPoint const&,
wxSize const&, long) .../espeak/src/espeakedit.cpp:279
[4] MyApp::OnInit() .../espeak/src/espeakedit.cpp:178
[5] wxEntry(int&, wchar_t**)
[6] main .../espeak/src/espeakedit.cpp:99
[7] __libc_start_main
[8] _start
-

This is on the src/espeakedit.cpp line:

notebook->AddPage(transldlg,_T("Text"),TRUE);

any ideas?

NOTE: Pressing 'Continue' on the dialog causes espeakedit to open and
display correctly. I haven't done any major testing, just fixed the
compilation and ensured it started correctly.

Thanks,
Reece H. Dunn (Cainteoir Technologies) [http://www.reecedunn.co.uk]
From fdf52edf89303bb25c15a114ed084f4c526a7e2c Mon Sep 17 00:00:00 2001
From: "Reece H. Dunn" 
Date: Sat, 16 Nov 2013 00:49:45 +
Subject: [PATCH 1/2] wxwidgets 3.0: make espeakedit compile

---
 src/compiledata.cpp  | 5 +
 src/espeakedit.cpp   | 7 +--
 src/extras.cpp   | 5 +
 src/spectdisplay.cpp | 8 
 src/spectseq.cpp | 5 +
 src/transldlg.cpp| 6 ++
 src/vowelchart.cpp   | 5 +
 7 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/src/compiledata.cpp b/src/compiledata.cpp
index 09645c3..4e22e81 100644
--- a/src/compiledata.cpp
+++ b/src/compiledata.cpp
@@ -1,6 +1,7 @@
 /***
  *   Copyright (C) 2005 to 2013 by Jonathan Duddington *
  *   email: jo...@users.sourceforge.net*
+ *   Copyright (C) 2013 by Reece H. Dunn   *
  * *
  *   This program is free software; you can redistribute it and/or modify  *
  *   it under the terms of the GNU General Public License as published by  *
@@ -42,6 +43,10 @@
 #include 
 #endif
 
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
 extern void FindPhonemesUsed(void);
 extern void DisplayErrorFile(const char *fname);
 extern int utf8_in(int *c, const char *buf);
diff --git a/src/espeakedit.cpp b/src/espeakedit.cpp
index e632c5a..4980e41 100644
--- a/src/espeakedit.cpp
+++ b/src/espeakedit.cpp
@@ -43,7 +43,10 @@
 #include "translate.h"
 #include "prosodydisplay.h"
 
-
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#define wxSAVE wxFD_SAVE
+#endif
 
 static const char *about_string2 = "espeakedit: %s\nAuthor: Jonathan 
Duddington (c) 2009\n\n"
 "Licensed under GNU General Public License version 3\n"
@@ -123,7 +126,7 @@ bool MyApp::OnInit(void)
 {//=
 
 int j;
-wxChar *p;
+const wxChar *p;
 char param[80];
 
 
diff --git a/src/extras.cpp b/src/extras.cpp
index fa6ac3b..2141a6e 100644
--- a/src/extras.cpp
+++ b/src/extras.cpp
@@ -1,6 +1,7 @@
 /***
  *   Copyright (C) 2006 to 2011 by Jonathan Duddington *
  *   email: jo...@users.sourceforge.net*
+ *   Copyright (C) 2013 by Reece H. Dunn   *
  * *
  *   This program is free software; you can redistribute it and/or modify  *
  *   it under the terms of the GNU General Public License as published by  *
@@ -35,6 +36,10 @@
 #include "translate.h"
 #include "options.h"
 
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
 extern char word_phonemes[N_WORD_PHONEMES];// a word translated into 
phoneme codes
 extern int __cdecl string_sorter(char **a, char **b);
 
diff --git a/src/spectdisplay.cpp b/src/spectdisplay.cpp
index efeb897..0904547 100644
--- a/src/spectdisplay.cpp
+++ b/src/spectdisplay.cpp
@@ -1,6 +1,7 @@
 /***
  *   Copyright (C) 2005 to 2007 by Jonathan Duddington *
  *   email: jo...@users.sourceforge.net*
+ *   Copyright (C) 2013 by Reece H.

wxWidgets 3.0 - espeakedit fixes

2013-11-15 Thread Reece Dunn 
Hi,

I have attached two patches for espeakedit:

0001-*.patch -- This makes espeakedit compile.

0002-*.patch -- This fixes a segfault when constructing the wxFont
objects for SpectFrame. These were being constructed in the global
namespace. With wxWidgets 3.0, it now requires a gtk+ window when
constructing a wxFont. The change moves creation of the fonts to the
SpectFrame constructor, so a SpectFrame object holds them internally.
I have also removed FONT_NORMAL as this was not used in the code.

These are also available on my espeak github repository at
https://github.com/rhdunn/espeak on the master branch.

NOTE: These changes should be backward compatible with wxWidgets 2.8.

Now when I try and run espeakedit I get:

-
ASSERT INFO:
../src/gtk/font.cpp(337): assert "IsOk()" failed in GetPointSize(): invalid font

BACKTRACE:
[1] wxFont::GetPointSize() const
[2] wxObject::operator=(wxObject const&) /usr/include/wx-3.0/wx/object.h:374
[3] MyFrame::MyFrame(wxWindow*, int, wxString const&, wxPoint const&,
wxSize const&, long) .../espeak/src/espeakedit.cpp:279
[4] MyApp::OnInit() .../espeak/src/espeakedit.cpp:178
[5] wxEntry(int&, wchar_t**)
[6] main .../espeak/src/espeakedit.cpp:99
[7] __libc_start_main
[8] _start
-

This is on the src/espeakedit.cpp line:

notebook->AddPage(transldlg,_T("Text"),TRUE);

any ideas?

NOTE: Pressing 'Continue' on the dialog causes espeakedit to open and
display correctly. I haven't done any major testing, just fixed the
compilation and ensured it started correctly.

Thanks,
Reece H. Dunn (Cainteoir Technologies) [http://www.reecedunn.co.uk]
From fdf52edf89303bb25c15a114ed084f4c526a7e2c Mon Sep 17 00:00:00 2001
From: "Reece H. Dunn" 
Date: Sat, 16 Nov 2013 00:49:45 +
Subject: [PATCH 1/2] wxwidgets 3.0: make espeakedit compile

---
 src/compiledata.cpp  | 5 +
 src/espeakedit.cpp   | 7 +--
 src/extras.cpp   | 5 +
 src/spectdisplay.cpp | 8 
 src/spectseq.cpp | 5 +
 src/transldlg.cpp| 6 ++
 src/vowelchart.cpp   | 5 +
 7 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/src/compiledata.cpp b/src/compiledata.cpp
index 09645c3..4e22e81 100644
--- a/src/compiledata.cpp
+++ b/src/compiledata.cpp
@@ -1,6 +1,7 @@
 /***
  *   Copyright (C) 2005 to 2013 by Jonathan Duddington *
  *   email: jo...@users.sourceforge.net*
+ *   Copyright (C) 2013 by Reece H. Dunn   *
  * *
  *   This program is free software; you can redistribute it and/or modify  *
  *   it under the terms of the GNU General Public License as published by  *
@@ -42,6 +43,10 @@
 #include 
 #endif
 
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
 extern void FindPhonemesUsed(void);
 extern void DisplayErrorFile(const char *fname);
 extern int utf8_in(int *c, const char *buf);
diff --git a/src/espeakedit.cpp b/src/espeakedit.cpp
index e632c5a..4980e41 100644
--- a/src/espeakedit.cpp
+++ b/src/espeakedit.cpp
@@ -43,7 +43,10 @@
 #include "translate.h"
 #include "prosodydisplay.h"
 
-
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#define wxSAVE wxFD_SAVE
+#endif
 
 static const char *about_string2 = "espeakedit: %s\nAuthor: Jonathan Duddington (c) 2009\n\n"
 "Licensed under GNU General Public License version 3\n"
@@ -123,7 +126,7 @@ bool MyApp::OnInit(void)
 {//=
 
 int j;
-wxChar *p;
+const wxChar *p;
 char param[80];
 
 
diff --git a/src/extras.cpp b/src/extras.cpp
index fa6ac3b..2141a6e 100644
--- a/src/extras.cpp
+++ b/src/extras.cpp
@@ -1,6 +1,7 @@
 /***
  *   Copyright (C) 2006 to 2011 by Jonathan Duddington *
  *   email: jo...@users.sourceforge.net*
+ *   Copyright (C) 2013 by Reece H. Dunn   *
  * *
  *   This program is free software; you can redistribute it and/or modify  *
  *   it under the terms of the GNU General Public License as published by  *
@@ -35,6 +36,10 @@
 #include "translate.h"
 #include "options.h"
 
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
 extern char word_phonemes[N_WORD_PHONEMES];// a word translated into phoneme codes
 extern int __cdecl string_sorter(char **a, char **b);
 
diff --git a/src/spectdisplay.cpp b/src/spectdisplay.cpp
index efeb897..0904547 100644
--- a/src/spectdisplay.cpp
+++ b/src/spectdisplay.cpp
@@ -1,6 +1,7 @@
 /***
  *   Copyright (C) 2005 to 2007 by Jonathan Duddington *
  *   email: jo...@users.sourceforge.net*
+ *   Copyright (C) 2013 by Reece H. Dun

Re: eSpeak command not emitting sound after disabling pulse audio

2013-10-24 Thread Reece Dunn 
On 24 October 2013 09:09, Sebastian Humenda  wrote:
> Hello,
>
> I have used the command suggested in the wiki to disable pulseaudio:
>
> dpkg-divert --add --rename /usr/share/alsa/pulse-alsa.conf
>
> Now, running commands like
> espeak "Hello World"
> does not work anymore. How can I configure eSpeak to use ALSA? I didn't find a
> command-line option to do so.

The eSpeak binary only supports pulseaudio or portaudio. IIUC,
portaudio should work with ALSA. To enable portaudio, make needs to be
invoked with either |AUDIO=runtime| (pulseaudio or portaudio) or
|AUDIO=portaudio|.

If that does not work, you can try building/using Cainteoir
Text-to-Speech (https://github.com/rhdunn/cainteoir-engine) which
supports eSpeak and ALSA. NOTE: The above command would be:

echo "Hello World" | cainteoir

It also supports many different document formats like HTML, RTF, ePub
and PDF. There is also a GTK+ GUI available
(https://github.com/rhdunn/cainteoir-gtk).

HTH,
- Reece H Dunn (Cainteoir Technologies)


-- 
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAGdtn26D3otO+Rzr9h_YD2xTrU4y_7QXsYEN8uOT=a-mris...@mail.gmail.com

Re: Accessibility talk at the GNU Hackers Meeting

2013-09-01 Thread Reece Dunn 
On 1 September 2013 13:04, MENGUAL Jean-Philippe  wrote:
> Ei,
>
> Le 30/08/2013 23:37, Reece Dunn a écrit :
>
>> On 30 August 2013 20:40, Samuel Thibault 
>> wrote:
>>>
>>> Hello,
>>>
>>> We had the opportunity to give a talk about accessibility at the GNU
>>> Hackers Meeting this summer, the video is available
>>>
>>>
>>> http://www.irill.org/videos/GNU_Hackers_Meeting_2013/Samuel_Thibault_Jean-Philippe_Mengual-Freedom_0_for_everybody_really.webm
>>
>> Thank you for an interesting presentation.
>>
>> I have an interest in speech synthesizers and am maintaining a branch
>> of espeak that makes it easier to build and work on in Linux (via
>> autotools) [https://github.com/rhdunn/espeak].
>>
>> Are there any features/functionality missing from espeak, along with
>> their priority?
>>
>> If the issue is of pronunciation accuracy, I have a pronunciation
>> dictionary command-line tool as part of my Cainteoir Text-to-Speech
>> engine project [https://github.com/rhdunn/cainteoir-engine] that can
>> be used to create and manage pronunciation dictionaries for languages
>> that can then be used to generate a _extra file with words that
>> eSpeak mispronounces. NOTE: I only currently support the default
>> British English voice phonemes, but can easily support others
>
> Cool thanks for information. In my opinion the main problem with Espeak is
> that the voice is not natural at all. Listening to it, we could really think
> that the computer is speaking but not any human voice. It's difficult to put
> up for "basic" users, despite numerous benefits of Espeak.

Thanks.

Currently, the only ways to make espeak sound more natural is to either:
a) use a klatt variant;
b) use an MBROLA voice.

The klatt2 and klatt4 variants sound the best out of the different
klatt variants, but they still have issues and I personally prefer the
original espeak voice to these).

The MBROLA voices sound a lot better, but MBROLA has usage
restrictions (cannot use it for commercial applications) and does not
provide the sources (so, e.g. it is not possible to get it building
with the raspberry pi).

Personally, I use the mb-de5-en voice as I personally think this is
the most natural out of all the different voices.

> Moreurer, having tested NVDA on Windows a few time ago, I've seen that
> Espeak is provided with a lot of variants. I wonder why they're not
> available on Linux. These variants are for French language, but I guess
> there're translated or they have equivalent. And why not present on standard
> Linux systems, where I feel that no update has come for Espeak to change its
> quality for years?

I wonder if these are the MBROLA voices?

Also, espeak has support for what it calls variants for voices -- male
(m1 through m7), female (f1 though f5), klatt (klatt, klatt1, klatt2,
klatt3, klatt4), whisper, whisperf and croak. These can be selected by
using the "+" voice syntax, for example:

$ espeak -v fr+klatt bonjour
$ espeak -v en+klatt2 "hello there"
$ espeak -v de+whisper "Guten Tag"

These variants are of varying quality and don't tend to sound as good
as the main espeak voice.

> Finally, I think Espeak could improve its "prosody", i.e. its voice while
> reading sentences, marking punctuation marks. So far we don't see any
> difference between a question mark, a dot, an exclamation mark. And all that
> with an English accent, even for other languages.

Yeah. I don't understand the espeak intonation/prosody logic that
well, so I don't know what is going on here or how to improve it.

>> NOTE: I also have a page on assessing the (subjective) quality of a
>> speech synthesizer at http://reecedunn.co.uk/cainteoir/design/quality
>
> Thanks. Very interesting.  I think it'd  worth to study speech synthetisers
> issue in the free software.

That is a good idea. It would also be worth testing the commercial TTS
engines (including MBROLA) along with the free software ones to get a
decent comparison.

There would also need to be a more scientific way of comparing them.
My quality page is a start, but this should have a more detailed score
card to be useful (i.e. a guideline on how to assess the different
quality aspects to reduce bias/subjectiveness -- e.g. eSpeak would be
marked down for not being able to identify different punctuation and
Cepstral Allison would be marked down for wildly varying pitch).

Thanks,
- Reece H. Dunn (Cainteoir Technologies)


--
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cagdtn27_nlaas7rznf60i8rtmwae2aqrehmqaz8hws+5hqt...@mail.gmail.com

Re: Accessibility talk at the GNU Hackers Meeting

2013-08-30 Thread Reece Dunn 
On 30 August 2013 20:40, Samuel Thibault  wrote:
> Hello,
>
> We had the opportunity to give a talk about accessibility at the GNU
> Hackers Meeting this summer, the video is available
>
> http://www.irill.org/videos/GNU_Hackers_Meeting_2013/Samuel_Thibault_Jean-Philippe_Mengual-Freedom_0_for_everybody_really.webm

Thank you for an interesting presentation.

I have an interest in speech synthesizers and am maintaining a branch
of espeak that makes it easier to build and work on in Linux (via
autotools) [https://github.com/rhdunn/espeak].

Are there any features/functionality missing from espeak, along with
their priority?

If the issue is of pronunciation accuracy, I have a pronunciation
dictionary command-line tool as part of my Cainteoir Text-to-Speech
engine project [https://github.com/rhdunn/cainteoir-engine] that can
be used to create and manage pronunciation dictionaries for languages
that can then be used to generate a _extra file with words that
eSpeak mispronounces. NOTE: I only currently support the default
British English voice phonemes, but can easily support others.

NOTE: I also have a page on assessing the (subjective) quality of a
speech synthesizer at http://reecedunn.co.uk/cainteoir/design/quality.

Thanks,
- Reece H Dunn (Cainteoir Technologies)


-- 
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cagdtn24tdrly5wwbylq4zkypg6vtxegdbyhnquv4-ecrh1f...@mail.gmail.com

Bug#707912: espeak: the AUDIO=runtime compilation ption does not invoke PulseAudio as intended

2013-05-13 Thread Reece Dunn 
On 13 May 2013 00:34, Jason White  wrote:

> Reece Dunn  wrote:
> > Are you sure the AUDIO=runtime flags are being set during the build?
> >
> > In line 30 of src/Makefile, espeak sets AUDIO=portaudio. This could be
> > overriding the AUDIO setting like CXXFLAGS were being overrided in bug
> > #707925.
> >
> > If AUDIO=runtime is built correctly, both wave.cpp and wave_pulse.cpp
> > should be compiled and -DUSE_PULSEAUDIO -DUSE_PORTAUDIO should be passed
> to
> > the compiler (see lines 37-39).
>
> Yes, indeed, and that's exactly what I see in the output of make during the
> compilation.
>
> It appears that variables specified on the make command line are treated
> differently from those brought in from the environment.
>

Then that should work...

The src/wave.cpp file contains the AUDIO=portaudio and AUDIO=runtime logic
and the src/wave_pulse.cpp file contains the AUDIO=pulse logic.

If both USE_PULSEAUDIO and USE_PORTAUDIO are defined, the wave API is
renamed from wave_xyz to wave_port_xyz for the portaudio bindings
(src/wave.cpp, lines 182-193) and to wave_pulse_xyz for the pulseaudio
bindings (src/wave_pulse.cpp, lines 80-91).

The AUDIO=runtime logic then uses the wave_xyz functions defined in
src/wave.cpp, lines 94-179 that uses either pulseaudio or portaudio.

The wave_init function calls is_pulse_running which returns 1 if calling
pa_simple_new returns a non-NULL pointer. If pulseaudio is running, the
wave_pulse_xyz APIs are called (which will call pa_context_new via
wave_pulse_init/pulse_open) otherwise the wave_port_xyz APIs are called
(which will call Pa_Initialize via wave_port_init).

Thus, with pulseaudio working you shoulds have the calls:
wave_init
is_pulse_running
pa_simple_new
wave_pulse_init
pulse_open
pa_context_new
and with pulseaudio not working, you should have the calls:
wave_init
is_pulse_running
pa_simple_new
wave_port_init
Pa_Initialize

Bug#707912: espeak: the AUDIO=runtime compilation ption does not invoke PulseAudio as intended

2013-05-12 Thread Reece Dunn 
Are you sure the AUDIO=runtime flags are being set during the build?

In line 30 of src/Makefile, espeak sets AUDIO=portaudio. This could be
overriding the AUDIO setting like CXXFLAGS were being overrided in bug
#707925.

If AUDIO=runtime is built correctly, both wave.cpp and wave_pulse.cpp
should be compiled and -DUSE_PULSEAUDIO -DUSE_PORTAUDIO should be passed to
the compiler (see lines 37-39).

The code in src/wave.cpp is doing the right thing, as I have built eSpeak
with AUDIO=runtime (not through this package) and it does not invoke
Pa_Initialize, but does invoke pa_simple_new.