<    April 2017    >
Su Mo Tu We Th Fr Sa  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 _2_8 29  
00:33 sgeorge joined
01:58 sgeorge joined
03:30 sgeorge joined
11:42 crienzo joined
12:14 sgeorge joined
13:49 <Chewi> crienzo: hey. after a lot of distractions, finally got around to putting simpleamd into place. it works pretty well though I'm not sure if I'm using it quite as intended. creating an amd detector at the start of the call, then playing a prompt and checking for dtmf while waiting for silence with another amd detector.
13:49 <Chewi> crienzo: thought I could swap the latter amd detector with vad but only ever seems to emit BEGIN events
13:50 <Chewi> crienzo: apart from that, I was wondering if options can be passed like it says on https://github.com/adhearsion/adhearsion-cpa. doesn't seem to work.
13:53 <Chewi> crienzo: looking at rayo_cpa_component.c, the only option that gets used is terminate?
13:54 <Chewi> cpa_signal->terminate = !zstr(url_params) && strstr(url_params, "terminate=true");
13:55 <crienzo> i'd have to see your config... might just be an issue there
13:55 <Chewi> there's not much
13:55 <Chewi> <detector name="simplevad">
13:55 <Chewi> <start application="simplevad_start" data=""/>
13:55 <Chewi> <stop application="simplevad_stop" data=""/>
13:55 <Chewi> <event class="CUSTOM" subclass="simpleamd::vad" value-header="Value">
13:55 <Chewi> <signal-type value="vad"/>
13:56 <Chewi> </event>
13:56 <Chewi> </detector>
13:56 <crienzo> ok, you only see the start of speech event
13:57 <Chewi> not VAD SILENCE or VAD VOICE
13:58 <crienzo> the SILENCE and VOICE events are the steady state events
13:58 <crienzo> the BEGIN events are the transition
13:58 <Chewi> maybe I'm misunderstand what the events mean then
13:59 <crienzo> they are internal and shouldn't be needed by you
13:59 <Chewi> if I want to check for a longer silence, I just need to increase voice_end_ms?
14:00 <crienzo> so the VAD will try to debounce things a bit, i believe
14:00 <crienzo> let me see
14:00 <crienzo> voice_end_ms will force the gaps between utterances longer in order to trigger silence state
14:01 <Chewi> exactly yes
14:01 <Chewi> my problem was that when testing this on a real answer machine, the silent state triggered too soon and the message got cut off
14:02 <crienzo> you could pass the param in your configuration
14:02 <Chewi> yeah, I'll do that if it isn't possibly through Adhearsion
14:02 <crienzo> i don't think i have a way to pass it in through adhearsion, though it wouldn't be hard to add
14:02 <crienzo> i have to check
14:03 <crienzo> i think it's because rayo is very high level and didn't define a way for me to pass detector specific params in
14:05 <Chewi> yeah, there doesn't seem to be quite the same detailed abstraction in CPA that you get with the other stuff. that's okay though.
14:05 sgeorge joined
14:12 <Chewi> <start application="simplevad_start" data="voice_end_ms=3000"/>
14:12 <Chewi> that doesn't seem to work
14:13 <Chewi> 2017-04-26 15:10:46.099305 [INFO] vad.c:270 11500: (voice) SILENCE DETECTED, total voice ms = 570
14:15 <Chewi> hmm possibly works if I put it in {}
14:15 <Chewi> 2017-04-26 15:15:28.247344 [INFO] vad.c:270 17470: (voice) SILENCE DETECTED, total voice ms = 2630
14:15 <Chewi> still less than 3000 though
14:16 <crienzo> yes.. it uses FS {} parsing function to pick out the params
14:16 <Chewi> was only 1130 on the next try
14:17 <crienzo> the total voice is not the same as the voice end ms
14:17 <Chewi> ah okay
14:17 <Chewi> that's fine then
14:17 <crienzo> it's measure of how much it heard
14:17 <Chewi> there's just one other problem. amd works but vad doesn't emit a silence event until there's been a voice event.
14:18 <crienzo> ok
14:18 <Chewi> if I don't say anything, it just waits and waits
14:18 <crienzo> so it probably needs to emit the initial state event
14:19 <crienzo> i think you can assume silence
14:19 <crienzo> if you want to tweak it, i'll accept a pull request. it should be simple to modify
14:19 <Chewi> in this case, we're assuming it's not silent to begin with and we're waiting for it to go silent. I should be able to figure this out so I'll send a request when I do.
14:20 <crienzo> i've never really used it in prod since I don't have a need for this kind of detector
14:20 <crienzo> you should get the voice event very quickly if it's not actually silent
14:21 <crienzo> but i see your issue- you don't want to deliver a message if it's not actually silent
14:21 <Chewi> yeah
14:22 <Chewi> thanks again for all this, it's a real help
14:22 <crienzo> sure, np
14:31 sgeorge joined
14:34 sgeorge_ joined
15:08 sgeorge joined
15:35 startledmarmot joined
16:13 <Chewi> crienzo: is it possible that the processing of the audio is delayed by 2-3 seconds?
16:13 <Chewi> I switched the debug level to 10 and I can see the energy levels are still high for a couple of seconds after I go quiet
16:14 <crienzo> are you running a jitter buffer?
16:14 <crienzo> some kind of weird lag...
16:14 <Chewi> I'm just using ekiga locally
16:14 <crienzo> it's a media bug so it should be instantaneous
16:15 <Chewi> on the plus side, I think I got that earlier problem figured out. I'll file a pull request in a bit.
16:15 <crienzo> great
16:26 <Chewi> tried with a real phone, seems better. I'll chalk it up to ekiga being shit.
16:37 <Chewi> https://github.com/crienzo/simpleamd/pull/1
17:04 <Chewi> crienzo: thanks for merging :D
17:04 <crienzo> np
19:21 startledmarmot joined
23:33 sgeorge joined