[Mono-dev] Festival TTS Wrapper

[buhochileno at gmail.com]

Hi:

recently I discover that the swig proyect help a lot generating most of 
the wrapper code, so I try with flite headers and create my a 
compilation set of .cs files, but at runing time I'm getting errors, but 
may be is worth to try it, or may be use it to traslate the freetts java 
code to c# to have a complete managed tts engine on mono, but i think 
that traslate freetts can be hard, the java source even interact with 
the sound card directly..is posible to use other voices with flite (like 
festival ones or mbrola voices.)...

Cheers,

Mauricio

R. Tyler Ballance 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!)
>
> 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
>
>