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
