[asterisk-dev] DTMF detection in dsp.c intolerant?

[Steve Underwood]

Tony Mountifield wrote:
> In article <fahn3f$jsq$1 at softins.clara.co.uk>,
> Tony Mountifield <tony at softins.clara.co.uk> wrote:
>   
>> In article <46CC5424.7030807 at coppice.org>,
>> Steve Underwood <steveu at coppice.org> wrote:
>>     
>>> I actually looked at the audio. Its seriously screwed up. Every digit 
>>> has two short beeps before it. Its consistent on every digit.
>>>       
>> Yes, it's very obviously poor audio, but spandsp still detects the digit
>> string correctly (kudos!).
>>
>> So it ought to be possible for Asterisk to do the same, given the same
>> sequence of samples. I'm just about to go through comparing Asterisk's dsp.c
>> with spandsp's dtmf.c to look for clues.
>>     
>
> Well one area that is different is in the debouncing of the DTMF hits.
>
> I did end up making a test wrapper around dsp.c, together with ulaw.c,
> alaw.c, frame.c and a few dummy functions. Feeding the audio files into
> it was quite revealing, with a few judicious printfs in dtmf_detect().
>
> It turns out that the problem with missing digits IS in the debouncing,
> for which I think the logic is wrong. I'll describe the problem in this
> post before I go away and work out how to correct it.
>
> The debouncing of hits within dtmf_detect() is currently as follows:
>
> if (hit) {
> 	if (hit == s->hits[2]  &&  hit != s->hits[1]  &&  hit != s->hits[0]) {
> 		// we register that we really have a digit
> 	}
> }
> s->hits[0] = s->hits[1];
> s->hits[1] = s->hits[2];
> s->hits[2] = hit;
>
> So hits[] is a shift register of old hits/non-hits.
>
> If we get a clean start of digit (say, 0), the sequence is as follows:
>
> (- - -) 0
> (- - 0) 0 : register that we have a digit (leading edge)
> (- 0 0) 0
> (0 0 0) 0
>
> However, if we get a bounce at the start, the whole digit can get missed:
>
> (- - -) 0
> (- - 0) -
> (- 0 -) 0
> (0 - 0) 0
> (- 0 0) 0
> (0 0 0) 0
>
> None of the above sequences triggers the leading-edge detector, which is
> looking for a match in the previous hit, preceded by two non-matches.
> Consequently the whole digit is missed.
>
> What should really happen is that the previous hit should match the
> current hit, and they should be different from the PREVIOUS DEBOUNCED
> HIT. It also appears that there is currently no debouncing of the
> trailing edge; the first non-hit terminates the digit.
>
> This is in 1.2, but I see the code in trunk is the same. I'll devise a
> suitable fix and post it to the bug tracker.
>
> Cheers
> Tony
>   
Does * still do that? The very early versions of the DTMF code did that, 
but I changed spandsp long ago. That hits array thing is badly broken. A 
number of phones don't work with it, because they start each digit in a 
very unstable manner. That might explain various quirky things I've 
heard people report about the DTMF detector in *. How come it has been 
like that so long? :-\

Steve