[asterisk-bugs] [Asterisk 0011968]: [patch] DSP cleanup phase 2

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11968 
====================================================================== 
Reported By:                dimas
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11968
Category:                   PBX/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 100974 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-10-2008 15:57 CST
Last Modified:              03-25-2008 05:46 CDT
====================================================================== 
Summary:                    [patch] DSP cleanup phase 2
Description: 
NOTE: these changes ara made on top of
http://bugs.digium.com/view.php?id=11796 so it must be applied first.
Publishing changes mainly for review.

1. Removed MUTECONF/MUTEMAX options support from DSP code. The idea behind
these is somewhat unclear and my analisys shows it is broken anyway -
http://lists.digium.com/pipermail/asterisk-dev/2008-January/031650.html

2. The code now generated DTMF_BEGIN frames in addition to DTMF_END ones.

3. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may
mark fragment of a frame for suppression (squelching, muting) with a call
to mute_fragment. Actual muting happens only once at the very end of
ast_dsp_process where all marked fragments are zeroed. This way every
detector sees original data in the frame without any piece of a frame being
zeroed by a detector which was run before.

4. DTMF detector tries to "mute" one block before and one block after the
block where actual tone was detected. Muting of previois block is something
new for this patch. Obviously this operation is not always possible - if
current frame does not contain data for previous block - it is too late.
But at least we make our best.

Muting of next block was already done by the old code but it only affects
part of the next block which is in the frame being processed. New code
keeps this information in state structures so it will mute proper number of
samples in the next frame(s) too.

5. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these
are not used anyway but would made patch more complicated if kept.

====================================================================== 

---------------------------------------------------------------------- 
 dimas - 03-25-08 05:46  
---------------------------------------------------------------------- 
qwell,
it looks like I understand MUTECONF/MUTEMAX stuff now. My current
understanding is that for MeetMe conferences (at least for Zap channels
involved), mixing of the voice streams is done not by the MeetMe
application itself but rather by TDMxxx board or by the Zaptel kernel
module. (Not sure who exactly does that but it is not the MeetMe app).
Because of this, all MeetMe participants hear DTMF tones geneated by Zap
members even when dsp.c removes these tones. The only way to prevent this
is to do zt_muteconf on Zap channel as soon as DTMF tone is detected. This
is what the old dsp.c tried to do - it was generating DTMF mute/unmute
frames which caused Zap channel driver to mute/unmute the conference. My
patch removes this code so I need confirmation this is Ok.

Personally I think this is ok because:
1. The code was broken anyway. It _intended_ to do proper muting/unmuting
but it did not work (
http://lists.digium.com/pipermail/asterisk-dev/2008-January/031650.html )
2. It looks like Digium wants to replace MeetMe with app_confbridge which
does not do any special processing fo Zap channels.
3. Even if you really want to to zt_confmute it should be done differently
- "generic" DSP should not generate some special frames. Instead it should
provide some API to let calling code ask "do you think we are in the middle
of some DTMF currently?" and Zap channel driver should query this API and
do muting/unmuting. After all, DSPs business is detection only, not some
channel-level control.

So if you can confirm that removal of this code is Ok, I will upload new
patch with your changes applied. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-25-08 05:46  dimas          Note Added: 0084478                          
======================================================================