[Mono-dev] Festival TTS Wrapper

[R. Tyler Ballance]

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!)

I'm tremendously busy during the week, but I'll post something this  
weekend after I'm able to set aside some time to get back to TTS and  
wrapping crazy interop code around legacy C (Flite's last release was  
almost 3 and a half years ago).

Glad to see somebody else is interested though! :)

Cheers,
-R. Tyler Ballance


p.s.  using Apple's Carbon APIs for Speech Synthesis, this  
hypothetical Mono.Speech API could also work on Mac OS X :-D