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

[Tony Mountifield]

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
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org