Please test this experimental multithreaded FliteController

Tagged: flite, Flitecontroller, multithreading, NSThread, pitch, speed, thread, variance

This topic has 3 voices, contains 7 replies, and was last updated by Halle 90 days ago.

Viewing 8 posts - 1 through 8 (of 8 total)

Author	Posts
Author	Posts
June 5, 2011 at 2:32 pm #4086
Halle	Hello there, For anyone who has been wishing for multithreaded Flite in OpenEars, you are welcome to test this experimental replacement for FliteController. Just download the following 2 classes and replace the existing classes in your known-working installation of OpenEars (it is better for your sanity and mine to not try to integrate this into an installation of OpenEars that is not quite working for you yet): http://www.politepix.com/wp-content/uploads/FliteController.h http://www.politepix.com/wp-content/uploads/FliteController.m The main implication of the fact that the voice generation occurs on a background thread is that calls to FliteController won’t block the thread on which you make them, which means that you can no longer time events that occur on your main thread by when FliteController finishes and returns, and any call to FliteController which occurs while another is in progress will cancel the earlier one, which means that you probably now need to pay attention to the OpenEarsEventsObserver delegate method: `- (void) fliteDidFinishSpeaking;` in order to know when the coast is clear to send a new phrase to FliteController. Let me know in this thread if you encounter any bugs or if it works for you, and have fun! If you use this code, you must mention that fact when asking a general question about OpenEars elsewhere in this forum so I have enough information to help. -Halle
June 23, 2011 at 12:32 pm #6913
Halle	Well, no one has gotten back to me on this but I’ve incorporated the speed/pitch/variance code into the current version .911 so there is no more reason to use this code in order to enable those voice features (I removed the references to them in the previous post to reduce confusion). You can still use this code if you want to try out multithreaded flite.
July 26, 2011 at 2:43 pm #7390
Halle	Moved new discussion about processing speed and streaming to a new topic here: http://www.politepix.com/forums/topic/flite-speech-synthesis-times-for-the-top-quality-voices
October 25, 2011 at 2:58 pm #7770
Joseph S. Wisniewski	FWIW, the mutlithreaded flite controller drops right into 0.913. It definitely makes my app a little more lively feeling.
October 25, 2011 at 3:04 pm #7771
Halle	Neat, glad to get the feedback. Pretty much the only thing holding me back from mainstreaming this is that I think the non-blocking behavior is a little trickier to understand from an API perspective, since you have to wait for the finished callback before sending new speech if you don’t want to interrupt existing speech.
October 27, 2011 at 3:56 pm #7805
Joseph S. Wisniewski	Oddly enough, the “confusing” behavior you describe was sort of what I was expecting. I tend to find blocking to be confusing, and sort of expect threading. Too much an old UNIX guy, I guess.
February 17, 2012 at 10:32 pm #8638
gotok	The multi-thread version works great for my app. Together with the observer method, I can duplicate the “flush” and “queue” modes of the Android text-to-speech. It’s no big deal copying the files over, but it would be nice to have an option in the OpenEarsConfig.h file to select either the normal or multi-thread versions. Anyway, I’m really glad that you provided the multi-thread version.
February 18, 2012 at 9:22 pm #8657
Halle	Thanks for the feedback! I’m giving it some consideration for the upcoming version of OpenEars.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.