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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150305/b51f4b8e/attachment.html>
