Hi, My PJSIP runs on a Linux-based ARM5 embedded system, it has an intermittent problem with audio path being dropped during the call setup after PJSIP makes a call and the incoming audio stream is about to start the echo cancellation process. When that happens, the system log will print out the following: 14:24:04.669 strm0x223e44 !RTP status: badpt=0, badssrc=0, dup=0, outorder=0, probation=-1, restart=0 14:24:04.670 pa_dev.c !Recorder thread started 14:24:04.670 ec0x228148 Prefetching.. 14:24:04.674 strm0x223e44 Start talksprut.. 14:24:04.675 os_core_unix.c Info: possibly re-registering existing thread 14:24:04.675 pa_dev.c !Player thread started 14:24:04.689 ec0x228148 Prefetching.. 14:24:04.709 ec0x228148 Prefetching.. 14:24:04.712 strm0x223e44 Jitter buffer empty (prefetch=0), plc invoked 14:24:04.733 tsx0x214bf4 !Timeout timer event 14:24:04.733 tsx0x214bf4 .State changed from Completed to Terminated, event=TIMER 14:24:04.733 tsx0x214bf4 Timeout timer event 14:24:04.733 tsx0x214bf4 .State changed from Terminated to Destroyed, event=TIMER 14:24:04.734 tsx0x214bf4 ..Transaction destroyed! 14:24:04.779 pa_dev.c !PA message: ContinuePoll: Trying to poll again for playback frames, pollTimeout: 19 14:24:04.780 pa_dev.c PA message: ContinuePoll: Trying to poll again for playback frames, pollTimeout: 19 14:24:04.780 pa_dev.c PA message: ContinuePoll: Trying to poll again for playback frames, pollTimeout: 19 14:24:04.780 pa_dev.c PA message: ContinuePoll: Trying to poll again for playback frames, pollTimeout: 18 14:24:04.781 pa_dev.c PA message: ContinuePoll: Trying to poll again for playback frames, pollTimeout: 18 until it gives up when pollTimeout reaches 0: 14:24:04.799 pa_dev.c PA message: ContinuePoll: Trying to poll again for playback frames, pollTimeout: 0 14:24:04.799 pa_dev.c PA message: ContinuePoll: Stopping poll for playback 14:24:04.800 ec0x228148 Prefetching.. 14:24:04.804 strm0x223e44 Jitter buffer starts returning normal frames (after 1 empty/lost) 14:24:04.805 ec0x228148 Prefetching.. 14:24:04.812 ec0x228148 Prefetching.. 14:24:04.816 ec0x228148 Latency bufferring complete And subsequently the capture part will stop: 14:24:04.954 pa_dev.c PA message: ContinuePoll: Stopping poll for capture 14:24:04.954 pa_dev.c PA message: CallbackThreadFunc: Input underflow 14:24:04.982 pa_dev.c PA message: CallbackThreadFunc: Input underflow 14:24:05.011 pa_dev.c PA message: CallbackThreadFunc: Input underflow 14:24:05.038 pa_dev.c PA message: CallbackThreadFunc: Input underflow ... 14:24:14.106 strm0x223e44 .......JB summary: size=25/eff=25 prefetch=0 level=2 delay (min/max/avg/dev)=20/160/106/40 ms burst (min/max/avg/dev)=1/2/1/0 frames lost=0 discard=417 empty=1 14:24:14.107 pjsua_media.c .......Media stream call00:0 is destroyed 14:24:14.107 tdta0x213b88 ....Destroying txdata Request msg ACK/cseq=31861 (tdta0x213b88) 14:24:14.108 tdta0x21cce0 ....Destroying txdata Request msg INVITE/cseq=31861 (tdta0x21cce0) 14:24:14.108 dlg0x2163a4 .....Session count dec to 1 by mod-invite 14:24:15.040 pjsua_acc.c Sending 2 bytes keep-alive packet for acc 0 to 72.1.46.10:5060 14:24:15.040 tdta0x21cce0 Destroying txdata raw 14:24:15.107 pjsua_aud.c Closing sound device after idle for 1 second(s) 14:24:15.107 pjsua_aud.c .Closing ghi2703c: (hw:0,0) sound playback device and ghi2703c: (hw:0,0) sound capture device 14:24:17.155 pa_dev.c .Stopping stream.. 14:24:17.155 pa_dev.c .PA message: PaUnixThread_Terminate: Canceling thread 1111856192 14:24:17.157 pa_dev.c !PA message: OnExit: Stopping ALSA handles 14:24:17.157 pa_dev.c PA message: AlsaStop: Dropped frames 14:24:17.157 pa_dev.c PA message: OnExit: Stoppage 14:24:17.158 pa_dev.c !.PA message: PaUnixThread_Terminate: Joining thread 1111856192 14:24:17.158 pa_dev.c .Done, status=0 14:24:17.381 pa_dev.c .Closing ghi2703c: (hw:0,0): 8 underflow, 0 overflow This problem happens because the CPU sometimes runs out of MIPS when EC is on, PortAudio timed out before it receives any playback frame from remote. I know that because once EC is turned off, this never happens. Removing other CPU intensive activities in the system during a call setup could alleviate the problem but can not eliminate it. My question is, is there a way to tune the PJSIP so that PortAudio is not so sensitive to such latency to give up so early? Thanks in advance, Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20140117/e5a42147/attachment-0001.html>
