[Mono-dev] Festival TTS Wrapper

[buhochileno at gmail.com]

Ok, I agree whith you about the FLite approach, what do you thing about 
MBrola and FestVox? or they have more restricted licences?. I think that 
FreTTS is also a god choice, becouse is java and probably more easy 
traslate to a complete managed TTS engine, and also may be provide 
compatibility with Microsoft's Synthesis API.

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