[Olympus developers 186]: Re: problem with apollo

[Thomas Harris]

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.

Thanks,
-Thomas

On Sat, Feb 20, 2010 at 11:48 PM, Benjamin Frisch <bfrisch at cs.cmu.edu>wrote:

> 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/20100224/929068b0/attachment.html