David D. Hagood wrote:
> Thomas Tonino wrote:
>
>> Roy Sigurd Karlsbakk wrote:
>>
>>> so - we DO NOT need a 'simplistic' DTMF decoder.
>>
>>
>>
>> You need a good one. But good can be simplistic, is what I'm saying.
>>
>> DTMF was designed to be easy to decode reliably. Complex doesn't
>> automatically mean better.
>>
>
> I haven't looked at the code, but I'd recommend using a bank of Goertzel
> filters -
>
>
>
http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=Goertzel+filter+DTMF&btnG=Google+Search
>
>
> The basic idea is that you have 8 filters (for the 4 row and 4 column
> frequencies), as well as 8 filters looking at the first harmonic of the
> 8 frequencies. You then compare the energies in each frequency - if you
> see significant energy in the harmonic filter bank, discard the signal.
> That prevents you from detecting speech as DTMF, since speech will
> usually have harmonics that a good DTMF signal won't.
That is done in the isdn_audio DTMF detection but did not work very well
with a number of phone sets I tested which seem to generate DTMF tones with
strong harmonics. They may be out of spec but they exist.
I have a patch which adds a simple energy comparison and some
plausablility checks to the DTMF eval code but does not look at the
harmonics. That improved the detection with above phone sets.
Maybe it would be better to reenable harmonic checks but comparing
harmonic levels to the level of the fundamental instead of using
absolute values as in the present implementation.
OTOH I don't think its a good approach to check harmonics anyway but to
check other non DTMF frequencies in the main speech band and only accept
a DTMF if a DTMF frequency pair is present but no signal on the non DTMF
frequencies (no signal = xxx dB below the detected DTMF levels).
There exists a long text about DTMF detection somewhere on the net (I
may have the link in the office but I'm on vacation now). What I
remember is that a "correct" DTMF detection requires much more computing
power as the present i4l implementation needs (much longer audio samples
for the goertzel filter, a larger number of frequencies to check) and a
standard test procedure with a lot of test cases which are not available
to mortal humans (audio tapes from Bellcore IIRC)
Wolfgang
>
> Since the Goertzel filters are simple, they can be implemented in fixed
> point math rather than floating point. At work, we've done this on a
> Motorola 56301 DSP, which is a fixed-point DSP. I think there's an app
> note from Moto on this - I'll check when I get into work today.
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--On Wednesday, January 08, 2003 16:49:06 +0100 Wolfgang Fritz
<[email protected]> wrote:
> That is done in the isdn_audio DTMF detection but did not work very well
> with a number of phone sets I tested which seem to generate DTMF tones
> with strong harmonics. They may be out of spec but they exist.
Distortion :-) Unfortunately, this stuff is cheap analog and even harmonic
distortion will create havoc with that algorithm.
By the way, if you happened to be trying this with Quicknet hardware, there
is a major overhaul to the driver coming that reduces the distortion levels
in the analog stages of the hardware immensely. (I suspect not as the
thread is about isdn)
> I have a patch which adds a simple energy comparison and some
> plausablility checks to the DTMF eval code but does not look at the
> harmonics. That improved the detection with above phone sets.
>
> Maybe it would be better to reenable harmonic checks but comparing
> harmonic levels to the level of the fundamental instead of using
> absolute values as in the present implementation.
It certainly would. And be relatively generous about the relative amount
of harmonic allowed; something like 30%. If you use absolute levels,
you're at the mercy of noise and level calibration errors, both of which
you have to assume are present. If you require the relative level to be
too low, you're at the mercy of distortion.
> OTOH I don't think its a good approach to check harmonics anyway but to
> check other non DTMF frequencies in the main speech band and only accept
> a DTMF if a DTMF frequency pair is present but no signal on the non DTMF
> frequencies (no signal = xxx dB below the detected DTMF levels).
>
> There exists a long text about DTMF detection somewhere on the net (I may
> have the link in the office but I'm on vacation now). What I remember is
> that a "correct" DTMF detection requires much more computing power as the
> present i4l implementation needs (much longer audio samples for the
> goertzel filter, a larger number of frequencies to check) and a standard
> test procedure with a lot of test cases which are not available to mortal
> humans (audio tapes from Bellcore IIRC)
There is a pretty good text linked in the source :-)
It's also near the top of a google for goertzel filter dtmf.
What I don't get is why the kernel links to this text, but implements one
of the algorithms that the conclusion of that paper rejects as unable to
satisfy the standard for DTMF detection? Maybe the original implementor
wanted to avoid doing matrix math in the kernel, or couldn't understand
what to do. The best algorithm was only twice as expensive in CPU, for
dramatically better reliability and standards compliance.
Andrew
Wolfgang Fritz wrote:
> There exists a long text about DTMF detection somewhere on the net (I
> may have the link in the office but I'm on vacation now). What I
> remember is that a "correct" DTMF detection requires much more computing
> power as the present i4l implementation needs (much longer audio samples
> for the goertzel filter, a larger number of frequencies to check) and a
> standard test procedure with a lot of test cases which are not available
> to mortal humans (audio tapes from Bellcore IIRC)
Take a look at this:
http://www-s.ti.com/sc/psheets/spra096a/spra096a.pdf
It describes an algorithm, plus test results. It was tested on a TI
DSP using those very Bellcore tapes, plus another set of tests, and
passes both tests very well.
Of course your ISDN hardware + phone handset may have much worse
analogue circuitry, but I would hope the Bellcore tapes represent that
to some degree.
Unfortunately, TI have removed the version of their application node
which includes DSP source code. It can be found here instead:
http://sulcata6.cs.ccu.edu.tw/~vlsi/data/c54x/spra096.pdf
I guess if that _exact_ DSP algorithm were recoded in C, you could be
reasonably confident that the C implementation would pass those
Bellcore and MITEL tests with reasonable analogue hardware. That's
probably the best you can do on the digital side.
enjoy,
-- Jamie
Wolfgang Fritz wrote:
> Maybe it would be better to reenable harmonic checks but comparing
> harmonic levels to the level of the fundamental instead of using
> absolute values as in the present implementation.
You mean the code DOESN'T normalize the signal to the total energy
first?!?!? YEEP!
The very FIRST thing you do is compute the total signal energy in the
sample period, trivially reject if Etotal < MinETotal, then normalize
all other signal energies to Etotal - that is a basic tenant of DSP.
> standard test procedure with a lot of test cases which are not available
> to mortal humans (audio tapes from Bellcore IIRC)
I think we may have the test cases as WAVs at work, and I think they are
freely distributable - I'll kick a reminder to my work account off to
check later today.