[pjsip] splitter/combiner bug report (was Re: conference port buffers not flushed?)

[Klaus Kuehnhammer]

hello,

i've traced this problem to the splitter/combiner. the samples get  
stuck in the delay buffer there.

it's very easily reproducable w/pjsua:
* #def STEREO_DEMO
* cc 1 0
* you should hear the right mic channel on the left speaker
* while blowing into the microphone, do 'cd 1 0'
* cc 1 0 -> you get the old samples

now, if i understand this right, i don't need the phase-reversed ports  
as implemented in the stereo demo code, and don't want the additional  
altency the delay buffers add.

i can't really figure out how to set up the splitter/combiner without  
them though.. i assume i need to add ports to the conf bridge like  
pjmedia_splitcomb_create_rev_channel does, but am not quite sure how i  
can install the right get_frame and put_frame callbacks to them from  
the application end.

the only hack i can think of is creating more ports in the pjsua_lib  
layer (w/ the local get and put frame callbacks), and retrieve them  
from there through some added method.. that way the additional ports  
would work and be added to splitcomb through  
pjmedia_splitcomb_set_channel like conf port 0.

but that can't really be right, can it?

any help would be greatly appreciated here, this is turning into a  
blocking issue for us :(

thanks!
Klaus


On Jun 4, 2009, at 4:16 PM, Klaus Kuehnhammer wrote:

> hi,
>
> i've run into the following problem (on v1.0.1, linux, audio path:  
> 12 ch alsa device <-> scomb <-> conf bridge; no VAD; G711/alaw):
>
> * make a sip call from another pjsua instance, connect an audio in  
> port to the call's port
> * play a sine wave into the corresponding line in
> * things are fine so far, the other side of the call hears the tone
> * disconnect the ports in the conf bridge
> * turn off the sine generator, wait a few seconds
> * re-connect the conf bridge ports
> * other side hears a short burst of the sine wave, and then silence
>
> analyzing the traffic w/ethereal shows that the problem is on the  
> sender side, the sine wave is there in the packets that go out after  
> the ports are reconneced.
>
> it looks like some old samples get stuck somewhere in the chain of  
> buffers, and are played out once the port gets re-connected.
>
> is this a known issue? any ideas where this most likely happens?
>
> thanks a lot for any help,
> Klaus
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org