Bill, Thank you very very much for your help, you really got me out of a starting depression xD Everything works out now, so I suppose that all my problems where due to maxing out the CPU, although I had the top command running, it never showed 100% CPU ussage. I can now make calls within my LAN, with that I can get on with my masters thesis. You have my gratitude, David On 2015-03-05 18:33, Bill Gardner wrote: > Hi David, > > The call in the log you sent is using speex 16 kHz codec, which will > use lots more CPU than PCM. Although you started the RPI with > --add-codec=PCMU, the INVITE is coming from ubuntu and it lists speex > 16k first. You can disable speex codec on either endpoint or start > ubuntu endpoint with --add-codec=PCMU which will then put PCMU first > in SDP in INVITE. > > Another point is that the resampler is high quality: > > > 15:53:20.267 resample.c .....resample created: high qualiy, large > filter, in/out rate=16000/48000 > 15:53:20.267 resample.c .....resample created: high qualiy, large > filter, in/out rate=48000/16000 > > You can change this to use faster lower quality filter in > site_config.h and rebuild, > I can't remember the precise macro but it's easy to find. > > Regards, > > Bill > > > On 3/5/15 11:01 AM, David Desopper wrote: >> Bill, >> >> First of all, thanks again for your help and trouble. >> >> I used the following command to start a pjsua instance on my RPI: >> ./pjsua-armv6l-unknown-linux-gnueabihf --no-vad --clock-rate=48000 >> --capture-dev=1 --playback-dev=3 --ec-tail=0 --add-codec=PCMU >> --log-file=log.txt >> >> As you see, I use diffrent devices as before to exclude the >> possibility that the problem has something to do with my sound >> device. I need to set the clock rate to 48000 or else I get an error >> in opening my sound devices. >> >> I also opened an instance of pjsua on my laptop with an Ubuntu 14.04 >> OS. From there I initialized a call using the ip adress of my RPI, so >> normally I stay local all the time. The log file from my RPI is >> included in attachment of this mail. >> >> This time a heard a very short burst of audio when the call was >> initially connected. But after that, I noticed the buffer message >> copied in my previous mail. When I hung up the call, the sound device >> closed correctly, but when issuing the "q" command to close PJSUA on >> my PI, the program hung, I had to kill the process. >> >> So now I'm thinking that something is going terribly wrong when the >> media packets are being processed, could this be because I set the >> clock-rate at 48k? >> >> Regards, >> David >> >> On 2015-03-05 16:19, Bill Gardner wrote: >>> Hi David, >>> >>> Those master sound underruns indicate your processor is not able to >>> keep up with media flow. But I don't recall seeing any such messages >>> in your earlier log. >>> >>> To reduce CPU consumption, disable echo cancellation, use fast >>> sample rate conversion, and use PCM codec. And make sure you are >>> running optimized (release) build. >>> >>> Regards, >>> >>> Bill >>> >>> >>> >>> On 3/5/2015 9:43 AM, David Desopper wrote: >>>> Bill, >>>> >>>> I am sorry for my numerous e-mails, but this problem is seriously >>>> bugging me because it is part of my master thesis, deadlines are >>>> creeping in fast. >>>> >>>> When I make a LAN call I get this information: >>>> >>>> Press a to answer or h to reject call >>>> a >>>> Answer with code (100-699) (empty to cancel): 200 >>>> 14:40:39.123 pjsua_call.c !Answering call 0: code=200 >>>> 14:40:39.126 pjsua_media.c ...Call 0: updating media.. >>>> 14:40:39.127 pjsua_aud.c ....Audio channel update.. >>>> 14:40:39.131 strm0x47bb44 .....Encoder stream started >>>> 14:40:39.132 strm0x47bb44 .....Decoder stream started >>>> 14:40:39.140 pjsua_media.c ....Audio updated, stream #0: PCMU >>>> (sendrecv) >>>> 14:40:39.141 pjsua_app.c ...Call 0 media 0 [type=audio], status >>>> is Active >>>> 14:40:39.142 pjsua_aud.c ...Conf disconnect: 2 -x- 0 >>>> 14:40:39.144 conference.c ....Port 2 (ring) stop transmitting to >>>> port 0 (Hercules HD Exchange: USB Audio (hw:1,0)) >>>> 14:40:39.146 pjsua_aud.c ...Conf connect: 3 --> 0 >>>> 14:40:39.147 conference.c ....Port 3 (sip:192.168.1.108) >>>> transmitting to port 0 (Hercules HD Exchange: USB Audio (hw:1,0)) >>>> 14:40:39.149 pjsua_aud.c ...Conf connect: 0 --> 3 >>>> 14:40:39.151 conference.c ....Port 0 (Hercules HD Exchange: USB >>>> Audio (hw:1,0)) transmitting to port 3 (sip:192.168.1.108) >>>> 14:40:39.154 Master/sound !Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> 14:40:39.153 pjsua_core.c ....TX 889 bytes Response msg >>>> 200/INVITE/cseq=12740 (tdta0x467ad8) to UDP 192.168.1.108:5060: >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/UDP >>>> 192.168.1.108:5060;rport=5060;received=192.168.1.108;branch=z9hG4bKPj9ErfYX2FuKbD1gEhQCuTMR7bhUmUYzm7 >>>> Call-ID: TR.3BVSkf3YKwlNsrT1D6-P0ffDN.r3X >>>> From: <sip:192.168.1.108>;tag=FJ6rb9ese.ANHOoZ9.CpfWsZxAZxcLzj >>>> To: <sip:192.168.1.124>;tag=mAL2aev6FkoPxy0h2PEHNm6Oi5CaZW90 >>>> CSeq: 12740 INVITE >>>> Contact: <sip:192.168.1.124:5060> >>>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, >>>> NOTIFY, REFER, MESSAGE, OPTIONS >>>> Supported: replaces, 100rel, timer, norefersub >>>> Session-Expires: 1800;refresher=uac >>>> Require: timer >>>> Content-Type: application/sdp >>>> Content-Length: 274 >>>> >>>> v=0 >>>> o=- 3634555234 3634555235 IN IP4 192.168.1.124 >>>> s=pjmedia >>>> b=AS:84 >>>> t=0 0 >>>> a=X-nat:0 >>>> m=audio 4000 RTP/AVP 0 96 >>>> c=IN IP4 192.168.1.124 >>>> b=TIAS:64000 >>>> a=rtcp:4001 IN IP4 192.168.1.124 >>>> a=sendrecv >>>> a=rtpmap:0 PCMU/8000 >>>> a=rtpmap:96 telephone-event/8000 >>>> a=fmtp:96 0-16 >>>> >>>> --end msg-- >>>> 14:40:39.161 pjsua_app.c .......Call 0 state changed to CONNECTING >>>> >>> 14:40:39.169 pjsua_core.c .RX 352 bytes Request msg >>>> ACK/cseq=12740 (rdata0x45c2bc) from UDP 192.168.1.108:5060: >>>> ACK sip:192.168.1.124:5060 SIP/2.0 >>>> Via: SIP/2.0/UDP >>>> 192.168.1.108:5060;rport;branch=z9hG4bKPjTBaR1hYODm1YOsSjR9ZXhlQzY211Rw0u >>>> Max-Forwards: 70 >>>> From: <sip:192.168.1.108>;tag=FJ6rb9ese.ANHOoZ9.CpfWsZxAZxcLzj >>>> To: sip:192.168.1.124;tag=mAL2aev6FkoPxy0h2PEHNm6Oi5CaZW90 >>>> Call-ID: TR.3BVSkf3YKwlNsrT1D6-P0ffDN.r3X >>>> CSeq: 12740 ACK >>>> Content-Length: 0 >>>> >>>> >>>> --end msg-- >>>> 14:40:39.171 ec0x46e880 !Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> 14:40:39.176 pjsua_app.c ...Call 0 state changed to CONFIRMED >>>> 14:40:39.243 ec0x46e880 !Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> 14:40:39.374 Master/sound Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> 14:40:39.431 Master/sound Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> 14:40:39.488 Master/sound Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> 14:40:39.544 Master/sound Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> 14:40:39.592 Master/sound Underflow, buf_cnt=0, will generate 1 >>>> frame >>>> >>>> >>>> Can this be the cause? >>>> >>>> On 2015-03-05 15:24, David Desopper wrote: >>>>> Never mind my last remark. The sampling rate has nothing to do >>>>> with it. >>>>> >>>>> Bill, can you tell me how to make calls within the same lan? >>>>> >>>>> >>>>> On 2015-03-05 15:06, David Desopper wrote: >>>>>> Bill, >>>>>> >>>>>> I now believe that this is a audio hardware issue instead of >>>>>> something else. To get my USB headset working, I have to set the >>>>>> clock-rate at 48kHz, can this be causing the problem in your >>>>>> opinion? This would shift the problem from PJSIP to Raspberry Pi >>>>>> hardware. >>>>>> >>>>>> >>>>>> On 2015-03-04 10:36, David Desopper wrote: >>>>>>> Bill, >>>>>>> >>>>>>> I normally did use a turn server in both endpoints. I will try >>>>>>> your solution and get back to you as soon as I did. >>>>>>> >>>>>>> Thank you, >>>>>>> David >>>>>>> >>>>>>> Bill Gardner schreef op 3/03/2015 om 22:29: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> OK. I see the call is connecting via a turn relay. Did you set >>>>>>>> up the ubuntu endpoint to use turn? It's surprising that ice >>>>>>>> didn't negotiate using the local RTP addresses on your LAN. >>>>>>>> Actually I can see that ice tests the local connection and it >>>>>>>> succeeds: >>>>>>>> >>>>>>>> 15:09:57.513 icetp00 ICE negotiation success after 0s:201 >>>>>>>> 15:09:57.515 icetp00 Comp 1: sending from host candidate 192.168.1.124:4015 to host candidate 192.168.1.110:4033 >>>>>>>> 15:09:57.516 icetp00 Comp 2: sending from host candidate 192.168.1.124:4001 to host candidate 192.168.1.110:4024 >>>>>>>> But then rasberry proceeds to use the media relay which seems >>>>>>>> wrong to me. I don't understand ice well enough to parse the >>>>>>>> issue from the logs. >>>>>>>> >>>>>>>> One suggestion is to drop all the registrar and ice/turn/stun >>>>>>>> options at both endpoints and just make the call between the >>>>>>>> LAN addresses, that should work and will verify you have >>>>>>>> working endpoints. Then you can go through the registrar and >>>>>>>> enable ice, which should negotiate the local RTP addresses. >>>>>>>> Then add turn relay to one or both endpoints. It should still >>>>>>>> use the local RTP addresses I would think. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Bill >>>>>>>> >>>>>>>> On 3/3/2015 3:35 PM, David Desopper wrote: >>>>>>>>> Bill, >>>>>>>>> >>>>>>>>> Thanks for your effort. I try to make calls between a pjsua >>>>>>>>> client on a raspberry on one side and a pjsua client on an >>>>>>>>> ubuntu system inside the same lan. I ran through the same >>>>>>>>> steps on both end sytems. It is puzzeling me for a while now >>>>>>>>> and I don't have a doubt in my mind that it's just me that's >>>>>>>>> doing something stupidly wrong. >>>>>>>>> >>>>>>>>> Bill Gardner schreef op 3/03/2015 om 21:28: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> The call stats show 8 packets sent and 449 received during an >>>>>>>>>> 8 second call. Given that you've checked the sound device >>>>>>>>>> using cc 0 0 it's puzzling that you don't hear any audio >>>>>>>>>> during calls. Are you sure the other endpoint is functional? >>>>>>>>>> One suggestion is to first make point to point calls between >>>>>>>>>> pjsip clients on your LAN before trying to connect to >>>>>>>>>> external clients. Another idea is to use wireshark to capture >>>>>>>>>> the RTP stream. >>>>>>>>>> >>>>>>>>>> The log looks OK to me, although I would expect more packets >>>>>>>>>> to be sent with vad off. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Bill >>>>>>>>>> >>>>>>>>>> On 3/3/2015 10:18 AM, David Desopper wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> For my master thesis I'm trying to use the pjsip libraries >>>>>>>>>>> for incorperated inside my own software project. But I can't >>>>>>>>>>> seem to be able to get pjsua working. Something clearly is >>>>>>>>>>> going wrong, but I have no idea what the problem seems to >>>>>>>>>>> be. If I check the sound quality paramaters during a call, I >>>>>>>>>>> can see that I am not transmitting any sound packets, but >>>>>>>>>>> also, I can't hear any sound that clearly is received. >>>>>>>>>>> >>>>>>>>>>> I did all the steps mentioned here: >>>>>>>>>>> https://trac.pjsip.org/repos/wiki/Audio_Problems/Getting_Around_Nat >>>>>>>>>>> but without succes. >>>>>>>>>>> >>>>>>>>>>> I also checked that my audio device is working by doing the >>>>>>>>>>> command cc 0 0 to echo my microphone input sound to my output. >>>>>>>>>>> >>>>>>>>>>> Pjsua is initialized like this: >>>>>>>>>>> >>>>>>>>>>> ./pjsua-arm-unknown-linux-gnueabihf --clock-rate=48000 >>>>>>>>>>> --capture-dev=0 --playback-dev=0 --use-ice >>>>>>>>>>> --id=sip:XXX at sip.antisip.com --registrar=sip:sip.antisip.com >>>>>>>>>>> --realm=* --username=XXX --password=*** >>>>>>>>>>> --stun-srv=stun.pjsip.org --no-vad >>>>>>>>>>> >>>>>>>>>>> I think that the most important output is this: >>>>>>>>>>> >>>>>>>>>>> 15:10:06.492 pjsua_app_comm ! >>>>>>>>>>> [CONFIRMED] To: >>>>>>>>>>> <sip:XXX at sip.antisip.com>;tag=kiGDpg9qCdBHKMLgabtKNN1RR-6zUtNP >>>>>>>>>>> Call time: 00h:00m:08s, 1st res in 7505 ms, conn in 7779ms >>>>>>>>>>> #0 audio PCMU @8kHz, sendrecv, peer=91.121.78.130:51526 >>>>>>>>>>> SRTP status: Not active Crypto-suite: >>>>>>>>>>> ICE role: Controlled, state: Negotiation Success, >>>>>>>>>>> comp_cnt: 2 >>>>>>>>>>> [0]: L:192.168.1.124:4015 (h) --> >>>>>>>>>>> R:192.168.1.110:4033 (h) >>>>>>>>>>> [1]: L:192.168.1.124:4001 (h) --> >>>>>>>>>>> R:192.168.1.110:4024 (h) >>>>>>>>>>> RX pt=0, last update:00h:00m:08.808s ago >>>>>>>>>>> total 449pkt 71.8KB (89.8KB +IP hdr) >>>>>>>>>>> @avg=62.8Kbps/78.5Kbps >>>>>>>>>>> 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 2.247 9.250 0.750 1.971 >>>>>>>>>>> TX pt=0, ptime=20, last update:00h:00m:04.429s ago >>>>>>>>>>> total 8pkt 1.2KB (1.6KB +IP hdr) @avg=1.1Kbps/1.3Kbps >>>>>>>>>>> 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 : 0.000 0.000 0.000 0.000 0.000 >>>>>>>>>>> RTT msec : 4.425 4.425 4.425 4.425 0.000 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I included the full log of the call in attachment. >>>>>>>>>>> >>>>>>>>>>> Thanks for your help >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150306/a84eabc1/attachment.html>
