Thanks Everyone. I am not sure if it is a ptime problem. Here is an excerpt of a log dump. You would notice that PJ has been initialized with 20/20 but while creating the sound stream, it gets a value of 800/100 (from where, I am not sure). any guidance on where to look? 08-17 19:12:43.998: DEBUG/SIPUA(1121): 19:12:44.005 os_core_androi pjlib 1.5.5-trunk for POSIX initialized 08-17 19:12:44.008: DEBUG/SIPUA(1121): 19:12:44.011 sip_endpoint.c Creating endpoint instance... 08-17 19:12:44.018: DEBUG/SIPUA(1121): 19:12:44.019 pjlib select() I/O Queue created (0x2dac8c) 08-17 19:12:44.018: DEBUG/SIPUA(1121): 19:12:44.020 sip_endpoint.c Module "mod-msg-print" registered 08-17 19:12:44.018: DEBUG/SIPUA(1121): 19:12:44.022 sip_transport. Transport manager created. 08-17 19:12:44.028: DEBUG/PJSUACORE(1121): @@@@@ IN PJSUA_MEDIA_CONFIG_DEFAULT with audio_frame_ptime:20, ptime:20 08-17 19:12:44.038: DEBUG/PJSUACORE(1121): %% INSIDE PJSUA_INIT with ptime PTIME:20 AUD_FRAME_PTIME:20 08-17 19:12:44.048: DEBUG/PJSUACORE(1121): sip ua intialized 08-17 19:12:44.048: DEBUG/PJSUA_MEDIA(1121): %%% INSIDE MEDIA_SUBSYS_INIT with PTIME=20 08-17 19:12:44.058: DEBUG/libpjsip(1121): initializing g711 codec 08-17 19:12:44.208: DEBUG/libpjsip(1121): Account Added result = 0 id = 0 08-17 19:13:17.648: DEBUG/CallEngine(1121): Call 0 state=org.pjsip.pjsua.pj_str_t at 43a34df8 08-17 19:13:17.798: DEBUG/PJSIP-SIP_INV(1121): ~~~ ON STATE CALLING NOW ~~~~~ 08-17 19:13:17.808: DEBUG/CallEngine(1121): Call 0 state=org.pjsip.pjsua.pj_str_t at 43a36760 08-17 19:13:17.998: DEBUG/PJSIP-SIP_INV(1121): ~~~ ON STATE CALLING NOW ~~~~~ 08-17 19:13:18.008: DEBUG/PJSIP-SIP_INV(1121): ~~~ ON STATE CALLING NOW ~~~~~ 08-17 19:13:18.008: DEBUG/Android_ADev(1121): ++++ Entering device create stream 08-17 19:13:18.018: DEBUG/Android_ADev(1121): creating sndstream 08-17 19:13:18.028: DEBUG/Android_ADev(1121): bufSz(2048),chanel(1),r(2047),w(0),samples_per_frame(800),bytes_per_frame(2), frame_duration(100) 08-17 19:13:18.028: DEBUG/Android_ADev(1121): stream(30bf64), rec_buf(30c31c), ext(30d31c), play_buf(0) On Mon, Aug 16, 2010 at 9:09 PM, Benny Prijono <bennylp at teluu.com> wrote: > On Tue, Aug 17, 2010 at 8:07 AM, Jeff Brower <jbrower at signalogic.com> > wrote: > >> > >> As receiver, client is required to be able to decode any packet length > >> (within reasonable limit), hence the ptime is not necessary for > >> decoding, and that's what pjsip does. > > > > Yes, but how does pjsip know packet length if it was not in the SDP at > call setup time? Does pjsip look at type of > > codec and packet length and calculate ptime? > > Yes. > > > I believe we've faced this problem before also (and had to force ptime > > manually). > > > > I don't know what that problem was, but if you think that was the > problem, try reproducing it with pjsua. > > >> The 100ms frame interval may have come from the ptime setting in > >> pjsua_media_config, which I assume your app has changed it to 100. > > > > I think the OP means "20 msec and 160 samples per packet". Otherwise, if > he really means "160 samples per second", > > then I have no idea what voice stream could be intelligible at 160 Hz > sampling rate. > > > > I was referring the 100ms in this: > > > When we analyzed why, we observed that when PJSIP receives their 183, it > > tries and creates an audio playback stream assuming it will receive > packets > > in 100 millisecond intervals and 800 samples per frame (that's what our > > dev_create_stream callback logs reports). > > Cheers > Benny > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100817/3a798cbe/attachment.html>
