2 is very important as some devices/applications do not work well with
silence suppression (notably Asterisk 1.2, which in spite of lots of
problems, is widely used).
Charlie
Alexander Chemeris wrote:
Hello,
On 2/7/07, Andrzej Ciarkowski <[EMAIL PROTECTED]> wrote:
I've already debugged it, and it is a question of frame classification.
AFAIR the code responsible for the classification is in MprEncoder (I'm on
holidays so I can't check it right now). The frames classified as silence
aren't pushed down the graph and are not sent onto the wire.
No, it is MprBridge who drop silence packets. This code in MprBridge::doMix()
search for active inputs:
// First, count how many contributing inputs
int inputs = 0;
int lastActive = -1;
for (int inIdx=0; inIdx < inBufsSize; inIdx++) {
if ( isPortActive(inIdx)
&& inBufs[inIdx].isValid()
&& inBufs[inIdx]->isActiveAudio())
{
inputs++;
lastActive = inIdx;
}
}
Speech type itself is detected in MprFromMic::doProcessFrame() now at
line 210:
out->setSpeechType(speech_detected(shpTmpFrame,n));
BTW, it is bad, VAD should be separated to MprVAD resource.
There several ways to workaround this:
1) And then if 'inputs == 0' it does not produce any output. If you do
not want this,
remove "&& inBufs[inIdx]->isActiveAudio()" from all ifs in MprBridge::doMix().
2) Disable VAD. I think interface from sipXtapi level should be created to
control this.
3) Copy 'MpMisc.comfortNoise' to output of MprBridge if all intputs are silent.
4) Make MprBridge more intelligent and implement real CN codec (this may be
combined with 3).
|
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
