[Olympus developers 183]: Re: problem with apollo

[Benjamin Frisch]

Hi All,
  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 inform.pm so you are alerted by voice if there
is a vad error.

Thanks,
Ben

On Sat, Feb 20, 2010 at 7:59 AM, Thomas Harris <thomas at edalytics.com> wrote:

> Hmm...
>
> 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.
>
> 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.
>
> Thanks,
> -Thomas
>
>
> On Wed, Feb 17, 2010 at 4:33 PM, Aasish Pappu <aasish at cs.cmu.edu> wrote:
>
>> Hi Thomas,
>>
>> 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.
>>
>> -Aasish
>>
>>
>> On 17 February 2010 16:09, Thomas Harris <thomas at edalytics.com> wrote:
>>
>>> 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).
>>>
>>> From Pocketsphinx:
>>> [STD at 15:55:47.691 (10909)] Processing command: engine_begin_utt 000 6070
>>>
>>>
>>> From Apollo, 40ms later:
>>> [WAR at 15:55:47.731 (10951)] Too much time since last partial result
>>> arrived (4381>2000),endpointing here, regardless of VAD.
>>>
>>> I'm finding it hard to say much in 40ms :)
>>>
>>> Thanks,
>>> -Thomas
>>>
>>
>>
>>
>> --
>> Aasish Kumar Pappu
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.srv.cs.cmu.edu/pipermail/olympus-developers/attachments/20100220/c519e94c/attachment.html