Don't worry, I have already the good config_site set. (And recently optimized). Everything is just fine with all other codecs (and even better, I have also ported the g729 port from samuel and also work really fine) GSM, speex etc are fine too. Nexus One has a 1GHz CPU and should be enough to support ilbc. My point is just a report to help the developer to find out what is going wrong with ilbc. There is maybe a regression or something bad with it. That's really strange that 20ms is really good and 30ms become absolutely unusable? Isn't it? But if we can support ilbc (as it is announced on the main page of pjsip), it would be really cool. Well not a necessity but if somebody has an idea on how to quickly fix it. Btw, I'll try to dive into the ilbc code to see were things can go wrong but if somebody else (with better knownledge of ilbc has any clue he will be welcome ;) ) Regards, R?gis 2010/8/17 M.Ali VARDAR <ali.vardar at gmail.com> > Hi, > > Dont use ilbc please use pcma or pcmu and you have to compile with MINIMAL > settings in config_site. > > > http://svn.pjsip.org/repos/pjproject/branches/projects/iphone/pjlib/include/pj/config_site_sample.h > > You can find more information in README file for compiling > > Best Regards > M.Ali VARDAR > > > > > 2010/8/17 R?gis Montoya <r3gis.3r at gmail.com> > > Sorry to update this topic but I think that I have some new clues on this >> issue. >> >> (As reminder I'm the developer of the port of pjsip for android). >> I have made a build with ilbc enabled. And I get the same logs that the >> one described on this thread. It's also on arm architecture but devices have >> a correct CPU (1Ghz). >> The result is that if I use ilbc with mode 20ms, things are really good, >> but if set mode to 30ms get exactly the same buffer resizing logs and sound >> is really bad. >> Maybe my audio driver is not well designed but don't think so since works >> well with all other codecs (and when ilbc mode is 20). >> Is there some constraints about buffers size/chunk read size on the audio >> driver? >> >> Regis >> >> >> 2010/4/25 Olle Frimanson <olle.frimanson at keystream.se> >> >>> Hi Bugra, >>> >>> >>> >>> We have also used pjsip on several different ARM?s so that is not the >>> issue, what might be worth checking is what samplings rates your codec >>> (AD/DA) supports. If it?s doesn?t supports 8000 resampling will be done in >>> ALSA driver I think and this could be a problem. >>> >>> >>> >>> Also have you tried the basic stuff like connect a local call in PJSUA, >>> play out a file and record from file does that work? >>> >>> >>> >>> BR/Olle >>> >>> >>> ------------------------------ >>> >>> *From:* pjsip-bounces at lists.pjsip.org [mailto: >>> pjsip-bounces at lists.pjsip.org] *On Behalf Of *Bugra Cakir >>> *Sent:* den 25 april 2010 10:03 >>> *To:* pjsip list >>> *Subject:* Re: [pjsip] Buffer problem >>> >>> >>> >>> No way out with PCMU and clockrate ! Shoulda try something else. >>> >>> >>> >>> ./pjsua-armv7l-unknown-linux-gnu --username=test7 --password=123 >>> --proxy=sip:85.123.66.44 --registrar sip:telekom.com --id >>> sip:test7 at turktelekom.com.tr --add-codec pcmu --dis-codec speex >>> --dis-codec ilbc --dis-codec GSM --dis-codec G722 --clock-rate=8000 >>> --snd-clock-rate=8000 --capture-dev=1 --playback-dev=0 >>> >>> >>> >>> >>> >>> 19:20:06.402 pjsua_app.c Call 0 is DISCONNECTED [reason=200 (Normal >>> call clearing)] >>> >>> 19:20:06.403 pjsua_app.c >>> >>> [DISCONNCTD] To: sip:03124818246 at telekom.com;tag=632633610 >>> >>> Call time: 00h:00m:28s, 1st res in 6678 ms, conn in 10920ms >>> >>> #0 PCMU @8KHz, sendrecv, peer=78.223.11.23:12240 >>> >>> RX pt=0, stat last update: 00h:00m:15.501s ago >>> >>> total 1.4Kpkt 230.2KB (288.0KB +IP hdr) @avg=57.0Kbps/71.3Kbps >>> >>> pkt loss=6 (0.4%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 >>> (0.0%) >>> >>> (msec) min avg max last dev >>> >>> loss period: 20.000 20.000 20.000 20.000 0.000 >>> >>> jitter : 0.000 0.313 11.625 0.125 0.824 >>> >>> TX pt=0, ptime=20ms, stat last update: 00h:00m:00.150s ago >>> >>> total 364pkt 58.2KB (72.8KB +IP hdr) @avg 14.4Kbps/18.0Kbps >>> >>> pkt loss=7 (1.9%), dup=0 (0.0%), reorder=0 (0.0%) >>> >>> (msec) min avg max last dev >>> >>> loss period: 20.000 46.667 100.000 20.000 32.731 >>> >>> jitter : 50.250 70.161 87.125 87.125 10.734 >>> >>> RTT msec : 12.054 15.701 17.456 12.054 2.131 >>> >>> 19:20:06.404 pjsua_media.c Media session for call 0 is destroyed >>> >>> 19:20:06.467 ec0x165cf8 Buffer size adjusted from 7194 to 6025 >>> (eff_cnt=5512) >>> >>> 19:20:06.669 ec0x165cf8 Buffer size adjusted from 7208 to 5784 >>> (eff_cnt=5512) >>> >>> 19:20:06.881 ec0x165cf8 Buffer size adjusted from 7527 to 6098 >>> (eff_cnt=5512) >>> >>> 19:20:07.037 ec0x165cf8 Buffer size adjusted from 7310 to 5871 >>> (eff_cnt=5512) >>> >>> >>> >>> >>> >>> On Apr 24, 2010, at 9:44 AM, P.Muge Ersoy wrote: >>> >>> >>> >>> Hi Bugra; >>> >>> I dont think it is a buffer problem.. >>> I compiled pjsip on arm processor and it was working just fine.. Here >>> what i did.. >>> I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h.. >>> >>> I ve never used iLBC codec.. coz it is too heavy for the processor.. >>> instead use G.711.. you will hear more proper voice.. >>> >>> Selamlar Muge :) >>> >>> >>> >>> On Sat, Apr 24, 2010 at 9:09 AM, Bugra Cakir <bugra.cakir at argela.com.tr> >>> wrote: >>> >>> Hi, >>> >>> I'm running pjsip-1.6 latest trunk on an beagle board based on ARM >>> processor. >>> While i'm running pjsua agent it is complaining about >>> >>> >>> 17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 >>> (eff_cnt=1440) >>> 17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 >>> (eff_cnt=1440) >>> 17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 >>> (eff_cnt=1440) >>> 17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 >>> (eff_cnt=1440) >>> 17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 >>> (eff_cnt=1320) >>> 17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 >>> (eff_cnt=1320) >>> 17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 >>> (eff_cnt=1230) >>> >>> >>> and after i initiate a call during 180 ringing and after 200 ok >>> >>> >>> 17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 >>> (eff_cnt=1198) >>> 17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 >>> (eff_cnt=1198) >>> 17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 >>> (eff_cnt=1198) >>> 17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 >>> (eff_cnt=1198) >>> 17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 >>> (eff_cnt=1198) >>> 17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 >>> (eff_cnt=1198) >>> 17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 >>> (eff_cnt=1198) >>> 17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 >>> (eff_cnt=1198) >>> 17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 >>> (eff_cnt=1198) >>> 17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 >>> (eff_cnt=1198) >>> 17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 >>> (eff_cnt=1138) >>> 17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 >>> (eff_cnt=1138) >>> 17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame >>> 17:24:06.950 sound_port.c EC suspended because of inactivity >>> 17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 >>> (eff_cnt=1138) >>> 17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 >>> (eff_cnt=1273) >>> 17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568 >>> (rdata0x176f5c) from UDP 2xx.1xx.1xx.xxx:5060: >>> BYE sip:test7 at 94.54.xx.xx:5060;transport=UDP SIP/2.0 >>> To: <sip:test7 at telekom.com.tr <sip%3Atest7 at telekom.com.tr> >>> >;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx >>> From: <sip:0312481xxxx@xxxxxxxxxxx <sip%3A0312481xxxx at telekom.com> >>> >;tag=D2055258867AF >>> Via: SIP/2.0/UDP 212.174.177.33:5060 >>> ;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport >>> Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD >>> CSeq: 27568 BYE >>> Contact: <sip:212.174.177.33:5060> >>> Max-Forwards: 69 >>> Content-Length: 0 >>> >>> >>> --end msg-- >>> 17:24:10.404 pjsua_core.c TX 358 bytes Response msg >>> 200/BYE/cseq=27568 (tdta0x1c3058) to UDP 2xx.1xx.1xx.xxx:5060: >>> SIP/2.0 200 OK >>> Via: SIP/2.0/UDP 212.174.177.33:5060 >>> ;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543- >>> Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD >>> From: <sip:0312481xxxx@xxxxxxxxxxx <sip%3A0312481xxxx at telekom.com> >>> >;tag=2055258867 >>> To: <sip:test7 at telekom.com <sip%3Atest7 at telekom.com> >>> >;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx >>> CSeq: 27568 BYE >>> Content-Length: 0 >>> >>> >>> --end msg-- >>> 17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal >>> call clearing)] >>> 17:24:10.406 pjsua_app.c >>> [DISCONNCTD] To: sip:0312481xxxxx at telekom.com<sip%3A0312481xxxxx at telekom.com> >>> ;tag=2055258867 >>> Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms >>> #0 iLBC @8KHz, sendrecv, peer=212.174.177.62:12060 >>> RX pt=113, stat last update: 00h:00m:02.478s ago >>> total 264pkt 13.1KB (23.7KB +IP hdr) @avg=4.5Kbps/8.2Kbps >>> pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%) >>> (msec) min avg max last dev >>> loss period: 0.000 0.000 0.000 0.000 0.000 >>> jitter : 0.000 3.042 18.250 1.250 4.373 >>> TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago >>> total 356pkt 17.8KB (32.0KB +IP hdr) @avg 6.2Kbps/11.1Kbps >>> pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%) >>> (msec) min avg max last dev >>> loss period: 0.000 0.000 0.000 0.000 0.000 >>> jitter : 26.000 39.125 52.250 52.250 13.125 >>> RTT msec : 28.030 32.760 37.490 37.490 4.730 >>> >>> >>> I'm hearing some part of voice activity from A and B party but they are >>> not accurate. >>> Is the problem related with media infrastructure or the platform it is >>> running on ? >>> >>> Thank you >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> _______________________________________________ >> 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 >> >> > > > -- > -------------------- > Sayg?lar?mla > M.Ali VARDAR > > > _______________________________________________ > 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/8f1687e4/attachment-0001.html>
