Buffer problem

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

 



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>


[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