Odd conference memory corruption issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> It's somewhat random, but the memory that gets corrupted is in
>> unallocated memory. The OS X malloc checks checksums on freed  
>> memory and
>> if it was modified after free, it will complain next malloc. This is
>> quite reproducible for me. I can't imagine it's PA, since setting the
>> conference level to zero causes the same problem, so the PA
>> implementation is sill getting good audio. Whether I disconnect the
>> sound input from the bridge or set the volume to zero, the bug  
>> appears.
>
> The interesting thing is this seems to only happen if the signal
> from the microphone is muted, either by muting the microphone
> (physically) or disconnecting the mic in the bridge (is it?). I'm
> having different behavior here with the same scenario. Here, instead
> of memory corruption, my playback (of the call) gets garbled if I
> disconnect the mic input, but this only happens with Speex and not
> with other codecs. I'm still working on this issue, and who knows
> maybe it's related to yours.
>
> What codec are you using?

I'm using PCMU. (Using it over a 100 Mbps LAN, I don't see a point in  
compressing.)

>> Speaking of which, does PJSIP do some sort of gain control? We are
>> having issues what something doing gain control that amplifies
>> background noise when a client isn't talking. I'm not sure if  
>> Asterisk
>> is doing it, PJSIP or PA.
>
> The only gain control in PJSIP is in the bridge. If you never call
> pjsua/pjmedia_conf_adjust_tx/rx_level() then no gain control is
> done. Having said that, the mixing functionality in the bridge also
> inherently adjusts the gain of the inputs, *if* more than one inputs
> are mixed together. When one sink output only receives from one
> input, the input signal will pass through unmodified.

I was thinking more dynamic or automatic gain control? We are  
struggling with background noise, and it seems something is  
amplifying it when the client's user isn't talking. In this case, it  
should just be the remote side going to the headset.

-Norman





[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux