Turns out there was a bug in Apollo after all. I've fixed it, and will check it in shortly. However, I'm a bit mystified about how the bug originated, which makes me uncertain about my bugfix. If anyone has logs from recent versions of Olympus that aren't having this problem, please send them to me.<br>
<br>Thanks,<br>-Thomas<br><br><div class="gmail_quote">On Sat, Feb 20, 2010 at 11:48 PM, Benjamin Frisch <span dir="ltr"><<a href="mailto:bfrisch@cs.cmu.edu">bfrisch@cs.cmu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi All,<br> In Olympus 2.5 you can switch to using PocketSphinx 0.5's VAD by setting the vad parameter in AudioServer's configuration to sphinx and setting utt_pause_final_duration_threshold to 100. That seems to solve most of the delay issues. There are also new max_utt_duration, min_utt_duration, partial_timeout_duration, and endpoint_feature_computation_delay parameter's in Olympus 2.5's Apollo. Finally, you may want to make sure that vad_error is properly set in Rossetta's <a href="http://inform.pm" target="_blank">inform.pm</a> so you are alerted by voice if there is a vad error.<br>
<br>Thanks,<br>Ben<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Sat, Feb 20, 2010 at 7:59 AM, Thomas Harris <span dir="ltr"><<a href="mailto:thomas@edalytics.com" target="_blank">thomas@edalytics.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hmm...<br><br>It appears that ultimately this is a problem with my computer. Audioserver it's actually getting samples at 16kHz, it's getting them a little slower, probably 11025, despite the configuration. I'm running xp as a guest os with vmware's fusion, so I'm guessing that the virtualization sounds drivers are not really fully functional. Anyway, the slower-than-expected samples caused audioserver to report times in the past, so when it told apollo that there was a vad event several seconds ago, apollo promptly complained that it hadn't heard any partial hypotheses and terminated the utterance.<br>
<br>So I guess running under fusion is out, although it might work with a USB mic, and of course it shouldn't have any trouble with voip.<br><br>Thanks,<br><font color="#888888">-Thomas</font><div><div></div><div>
<br><br><div class="gmail_quote">
On Wed, Feb 17, 2010 at 4:33 PM, Aasish Pappu <span dir="ltr"><<a href="mailto:aasish@cs.cmu.edu" target="_blank">aasish@cs.cmu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Hi Thomas,</div><div><br></div>If you are using Olympus 2.5, then it uses sphinx VAD(I presume) for endpointing. If not, then you may want to see if the IMCore.cpp has any magic configuration (precisely Pause Threshold and other thresholds ) written inside the code. I know that Ben wanted to put that magic configuration out of the code into AudioServer.cfg, but I am not sure if it is the case.<div>
<br></div><div>-Aasish<div><br><br><div class="gmail_quote">On 17 February 2010 16:09, Thomas Harris <span dir="ltr"><<a href="mailto:thomas@edalytics.com" target="_blank">thomas@edalytics.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm having an endpointing issue with the olympus trunk on an application built with mostly meetingline configs. Everything is getting prematurely endpointed. It looks like a bug in Audioserver or its configuration. Has anyone seen this, or better yet (not seen it with some particular version and config).<br>
<br>From Pocketsphinx:<br>[STD@15:55:47.691 (10909)] Processing command: engine_begin_utt 000 6070 <br><br>From Apollo, 40ms later:<br>[WAR@15:55:47.731 (10951)] Too much time since last partial result arrived (4381>2000),endpointing here, regardless of VAD.<br>
<br>I'm finding it hard to say much in 40ms :)<br><br>Thanks,<br><font color="#888888">-Thomas<br>
</font></blockquote></div><br><br clear="all"><br></div>-- <br>Aasish Kumar Pappu<br><br><br>
</div>
</blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>