On 2/7/07, Alexander Chemeris <[EMAIL PROTECTED]> wrote: > 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. I was not fully correct here. MprBridge does not produced packets if voice is not active. But even if MprBridge pass packets, marked as silence, for further processing, MprEncode drop them. I commited fix for MprBridge behaviour for simple 1-to-1 case. However, it is not good fix, the way MprBridge work should be revised and rewrote to support complex cases. If anybody want participate - you're welcome.
> 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(). Already done by me. > 2) Disable VAD. I think interface from sipXtapi level should be created to > control this. This should be done in either way. Charlie was right about compatibility with dumb soft and hardware. Volunteers are welcome. > 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). Still applicable. Volunteers are welcome. -- Regards, Alexander Chemeris. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
