Linphone frequently crashes using G.729 codec

Bug #1190877 reported by gdi2k
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linphone (Ubuntu)
New
Undecided
Unassigned

Bug Description

I'm on Ubuntu using 12.10 linphone and linphone-plugin-g729 from the PPA here:
https://launchpad.net/~linphone/+archive/release

When using ulaw, things are rock solid, but using G.729 causes linphone to crash a few times per day when in constant use.

linphone is running as an LTSP local app, but that shouldn't make any difference.

I am happy to provide debugging info, but not sure what to include.

Tags: g729 linphone
Revision history for this message
gdi2k (gdi2k) wrote :
Download full text (5.8 KiB)

To try and provide more useful info, I enabled logging and waited for a crash. Here are the last few seconds:

[20130614-15:39:48] [message] CALL_ACK
[20130614-15:39:48] [message] Samples are back.
[20130614-15:39:48] [warning] Not enough ref samples, using zeroes
[20130614-15:39:48] [message] Samples are back.
[20130614-15:39:49] [message] bandwidth usage: audio=[d=28.2,u=27.3] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:49] [message] Thread processing load: audio=8.152800 video=0.000000
[20130614-15:39:50] [message] bandwidth usage: audio=[d=23.9,u=24.4] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:50] [message] Thread processing load: audio=12.033092 video=0.000000
[20130614-15:39:51] [message] bandwidth usage: audio=[d=24.1,u=24.1] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:51] [message] Thread processing load: audio=13.539887 video=0.000000
[20130614-15:39:51] [message] alsa: sound/wall clock skew is average=-44.164027 ms, instant=-49 ms
[20130614-15:39:51] [message] cb_nict_kill_transaction (id=10)
[20130614-15:39:51] [message] eXosip: timer sec:4 usec:404614!
[20130614-15:39:52] [message] bandwidth usage: audio=[d=24.4,u=24.7] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:52] [message] Thread processing load: audio=13.448652 video=0.000000
[20130614-15:39:53] [message] bandwidth usage: audio=[d=23.5,u=24.3] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:53] [message] Thread processing load: audio=11.457193 video=0.000000
[20130614-15:39:53] [message] alsa: sound/wall clock skew is average=-45.705027 ms, instant=-48 ms
[20130614-15:39:53] [message] audio_stream_process_rtcp: interarrival jitter=589 , lost packets percentage since last report=0.000000, round trip time=0.188950 seconds
[20130614-15:39:53] [message] MSQosAnalyser: lost_percentage=0.000000, int_jitter=73.625000 ms, rt_prop=0.188950 sec
[20130614-15:39:53] [message] MSQosAnalyser: everything is fine.
[20130614-15:39:53] [message] MSBitrateController: current state is Init
[20130614-15:39:54] [message] bandwidth usage: audio=[d=24.4,u=24.4] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:54] [message] Thread processing load: audio=13.079607 video=0.000000
[20130614-15:39:55] [message] bandwidth usage: audio=[d=24.3,u=24.1] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:55] [message] Thread processing load: audio=12.779621 video=0.000000
[20130614-15:39:55] [message] cb_nict_kill_transaction (id=8)
[20130614-15:39:55] [message] free transaction resource 8 571bae9b359660c116b7d6c26f0035cd
[20130614-15:39:55] [message] free nist resource
[20130614-15:39:55] [message] keep alive: 0
[20130614-15:39:55] [message] eXosip: Keep Alive sent on UDP!
[20130614-15:39:55] [message] eXosip: Reseting timer to 10s before waking up!
[20130614-15:39:56] [message] bandwidth usage: audio=[d=24.2,u=24.7] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:56] [message] Thread processing load: audio=15.170906 video=0.000000
[20130614-15:39:56] [message] alsa: sound/wall clock skew is average=-46.980136 ms, instant=-47 ms
[20130614-15:39:57] [message] bandwidth usage: audio=[d=23.7,u=24.0] video=[d=0.0,u=0.0] kbit/sec
[20130614-15:39:57] [message] Thread processing load: audio=11.932424 video=0.000000
[2013061...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.