Just to add, I found that using espeak to generate a .wav file and then sending it through aplay/play, seem to be more responsive than allowing espeak to play the sound. Regards, Willem On Wed, 9 Aug 2006, Hynek Hanke wrote: > Lorenzo Taylor p???e v St 09. 08. 2006 v 15:41 -0400: >> As for the cut-off bug I mentioned, I am using speech-dispatcher when it >> happens. Unfortunately, I can't reproduce it using the speak command >> directly, either using the -f option to read it from a file or sending >> it on the command line. However, the problem seems to go away when I >> change the espeak-generic.conf file in speech-dispatcher so that it >> creates a wav file and uses aplay to play it. Note that this is how the >> espeak-generic.conf file that is shipped with speech-dispatcher works. >> I had just changed it to eliminate the extra step. But apparently >> somehow that was causing the problem, although I'm not sure why. > >> From your description, here is my guess of what happens. One of the > requierements for the command used with the generic output module is > that the command blocks exactly until all audio is played and then it > returns so that Speech Dispatcher knows when it can start playing the > next part. This is what is guaranteed using aplay to play the sound. > > Maybe if you use eSpeak to play the sound, sometimes it just returns > after it puts all the data into the sound output buffer (but some > of the data are still not played on the speakers). If you try this > with a command line, you don't notice. But if you use the generic > output module, it sends the text sentence by sentence and if the eSpeak > returns early, it will just send another sentence, which will interrupt > the previous one. > > We could now ask Jonathan to try to confirm this and if so, then fix it. > But it is difficult for me to call this a bug. In my opinion, it is not > worth the time trying to fix it. Audio output is a complex and hard > thing and there is no reason (in good design) why a speech synthesizer > should have to take care of it. The future architecture of the eSpeak > module in Speech Dispatcher will retrieve audio and play it with its own > library for all different synthesizers -- the code on the side of eSpeak > is already ready thanks to Jonathan. In the meantime when we use the > generic output module, using some well tested robust technology like > aplay seems to be a reasonable solution. > > But if my guess as for the cause of the bug is incorrect, e.g. the bug > happens even with aplay, then please let me know. Also, I wonder if > there are some troubles with aplay or what is the improvement from > removing aplay from the command chain. Maybe I could help to fix this > issue while still using aplay. > > Thank you, > Hynek Hanke > > > _______________________________________________ > Speakup mailing list > Speakup at braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup > -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support.
