[Mono-dev] Festival TTS Wrapper

[Jonathan Morgan]

On Oct 30, 2007 4:23 PM, R. Tyler Ballance <tyler at monkeypox.org> wrote:
>
> On Oct 29, 2007, at 4:17 PM, buhochileno at gmail.com wrote:
>
> > Sorry to disapoint you, but my wrapper is not even a "server" call
> > to the festival TTS, is more cheating :-), is only a wrapper for a C
> > shared library that send the correct "echo $MESSAGE | festival --
> > tts" :-) , I also see the posibility to try a more sofisticate
> > wrapper, but as you say is to much complicate, so this is a working
> > approach :-)
>
> A novel approach to say the least, but I agree, it's not great, but
> it's a start :)
>
> > I attach the C shared library and the C# wraper with a simple test
> > program.
> >
> > May be we can work in a better wrapper.
>
> I also agree on this :)
>
> I think we should consider approaching "managed text-to-speech" from
> the side of Flite instead of Festival (I think lupus actually
> suggested this when I was first discussing it on #mono, but I
> foolishly went ahead with trying for Festival anyways). The one core
> thing I started to do with my wrapper (from here out referred to as
> Tao.Festival) was provide support for both a server-oriented Festival
> interface, i.e. connecting on the Festival's port (1234 I believe) and
> then performing the commands, or using a C#->C->C++ wrapper I had
> written to take advantage of libFestival.a which is usually installed
> on most Linux systems when the Festival package is added. I had not
> started on the server-oriented code yet, but had the wrappers in place
> for relying on libFestival which proved to be "a stupid idea" and will/
> would cause the entire Mono process to SIGSEGV every single time
> because of some of the intricacies to native platform interop with
> code that's *so* expectant on being statically linked *always* as
> Festival is. I can upload the code to my anonymous Subversion
> repository, but I think it's only worth it from a "research"
> perspective in seeing why exactly Festival is a bad route to go with :)
>
> Our end goal is easy to define I think, ideally we would want to
> provide developers with the following calls:
>         Mono.Speech.SayText("Hello Monkeys!");
>         Mono.Speech.SayText("Hello Monkeys!", FileStream,
> Mono.Speech.WaveFileType);
>
> I suggest you look at the following for an idea on why Flite will be
> far easier:
>         http://www.speech.cs.cmu.edu/flite/doc/flite_7.html#SEC17
>
> I will try to port my existing design of Tao.Festival over to
> something more Flite-based this weekend, at the very least to evaluate
> whether or not Flite will truly be a better option than Festival, and
> to evaluate whether the concept will *actually* work.
>
> As much as I would love to be able to provide compatibility with
> Microsoft's new System.Speech.Synthesis API, I just don't think that's
> ever going to be possible given the state of open source speech
> synthesis systems (unless somebody writes a fully managed one on Mono
> of course :)). So maybe would should just strive for providing
> something that Gtk# developers can use, specifically in some of the
> applications Novell includes in their SUSE distribution (how cool
> would it be for Banshee to tell you what song it's "spinning up" next
> like a DJ!)

If you are looking for a fully managed solution, you could look at
FreeTTS <http://freetts.sourceforge.net>, which is a (from memory
Sun-backed) port of flite to Java.  It's supposed to be considerably
faster than flite and may provide a good base for a .NET version
(IKVM, C#, or whatever else).

Jon