Choppy sound when multitasking

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Issue or answer a call with sip over wifi
2. While call in progress, switch to home screen and launch some application, 
either that make or not traffic on wifi 

What is the expected output? What do you see instead?
Expected still clear and continuos sound, instead when the o.s. and/or 
application are using the cpu sound is choppy

What version of the product are you using? On what operating system?
0.00-15-10, HTC Wildfire 2.1 Eclair

Original issue reported on code.google.com by karnevil...@gmail.com on 11 Nov 2010 at 2:09

[GoogleCodeExporter]

Do you know what codec is in use when it appear? 
Some codecs consume a lot of CPU.

I've just tested on my Nexus One and even if I launch an app that use network, 
voice quality is still fine.
The other app you launch doesn't try to use audio? 

Original comment by r3gis...@gmail.com on 11 Nov 2010 at 6:29

[GoogleCodeExporter]

It's the PCMU, that's supposed to be less CPU intensive at price of highest 
data rate.

Applications are just system applications like contact browsing or internet 
browser, none of those use audio.

After detecting such issue I made another test. I ran TuneIn Radio connected 
via wifi to a 128kbps internet radio stream. This played always perfect (and 
with good quality) in any case, like terminal in complete standby or 
multitasking with other applications, even with internet browser. I tried such 
application both with 'use internal MP3' on and off.

Good thing is that I used TuneIn for all this afternoon and for each incoming 
sip call TuneIn has stopped playing, restarting automatically when call 
terminated, showing good integration of such application and csipsimple into 
the o.s.

Original comment by karnevil...@gmail.com on 11 Nov 2010 at 10:11

[GoogleCodeExporter]

Confirming this issue on csipsimple versions 00.13, 00.15-18, and 00.16-00 
running on HTC Wildfire with CyanogenMod 6.1-RC2 (Android 2.2.1).  Whenever 
switching away from the call screen, audio breaks up badly, and the break-up 
seems worse with more foreground activity.  Tested with PCMU codec.

Original comment by fander...@gmail.com on 9 Dec 2010 at 8:09

[GoogleCodeExporter]

Can someone test revision 422 :

http://nightlies.csipsimple.com/trunk/CSipSimple-r422-trunk.apk

I've re-worked the audio "driver" I'd so really appreciate any feedback on this 
new version.

Original comment by r3gis...@gmail.com on 10 Dec 2010 at 3:45

[GoogleCodeExporter]

Also worth to try with 8kHz as frequency (CPU usage will be less important 
since in this case no resampler is needed).

Original comment by r3gis...@gmail.com on 10 Dec 2010 at 3:48

[GoogleCodeExporter]

Sorry 422 was absolutely broken 
http://nightlies.csipsimple.com/trunk/CSipSimple-r427-trunk.apk

revision 427 should be ok.

Original comment by r3gis...@gmail.com on 11 Dec 2010 at 5:33

[GoogleCodeExporter]

With revision 427, when I set up an account using the callcentric wizard, then 
save it, then change the wizard for the account to expert, then try to modify 
the settings, csipsimple FCs every time.

Original comment by fander...@gmail.com on 11 Dec 2010 at 6:49

[GoogleCodeExporter]

427 also doesn't have a noticeable impact on the audio problems for me: if I 
switch away during the call, the audio still breaks up badly when there's any 
foreground activity (e.g. opening the app drawer from the home screen).

Original comment by fander...@gmail.com on 11 Dec 2010 at 6:56

[GoogleCodeExporter]

r427 tested, same choppy sound as before

Original comment by karnevil...@gmail.com on 28 Dec 2010 at 1:03

[GoogleCodeExporter]

After implementing the android 2.3 audio driver with OpenSL-ES support and 
reading a lot of docs from android sound "masters", I think that this problem 
is inherent to the *non* OpenSL-ES driver (the one that is shipped with all 
CSipSimple version except the gingerbread edition available on nightly build 
website).

As this driver pass its audio frames to the JVM it is impacted by the JVM 
garbage collector process that may freeze the process. It's probably more 
noticeable on devices that has less RAM or are configured to do more agressive 
garbage collection.
The OpenSL-ES driver is not affected by this problem. So OpenSL-ES driver will 
fix this issue. Problem is that you'll need android 2.3 on your device ... But 
that's the ~only~ solution I think. (*only Excepted the old pure native driver 
that use private apis and is as consequence not portable).

Original comment by r3gis...@gmail.com on 27 Feb 2011 at 10:50

• Changed state: WontFix

[GoogleCodeExporter]

You wrote that the OpenSL driver should fix this, but I'm using it (ginger 
build) and it doesn't fix it.  The problem is the same as it's always been: as 
soon as you switch away from the in-call screen and perform a task that uses 
some CPU, like simply opening/closing the app drawer, the call audio breaks up 
completely and then comes back when the task finishes.  I don't think this is 
due to GC.

Original comment by fander...@gmail.com on 27 Feb 2011 at 11:00

[GoogleCodeExporter]

I confirm that if I try to do something while in call (e.g. lookup in 
addressbook or make notes), sounds becomes choppy while another program is 
doing something. I attribute this to other processes being given longer CPU 
timespans by the Linux dispatcher than there is data in the the audio buffers 
to (just a theory, no proof of that). This probably is "normal behavior", and 
could be remedied by giving the process that does sound stream processing 
realtime priority. I have no knowledge if this is possible or advisable to do 
in Android.

Original comment by egcros...@gmail.com on 28 Feb 2011 at 9:14

[GoogleCodeExporter]

Thread that manage audio stream already ask for has the correct thread priority 
(the one for high priority audio).
AFAIK it is taken into account by android ... I think so cause looking at 
thread priority using ps seems to be good...
However Dalvik JVM behaves strangely sometimes. 

It could be interesting to monitor CPU while doing something else. If it reach 
the 100% of load, I guess you're probably right, that's not something with GC 
but something with CPU.

If you have android 2.3 could be interesting to compare with the perf of the 
stock SIP application when multitasking.

Original comment by r3gis...@gmail.com on 28 Feb 2011 at 9:34

[GoogleCodeExporter]

I've just installed 2.3.3; I'll do some experimenting one of these days if I 
have a chance, and report.

Original comment by egcros...@gmail.com on 28 Feb 2011 at 9:45

[GoogleCodeExporter]

OK, both latest trunk #682 and latest ginger #675 give choppy sound when I try 
to browse while talking. Native SIP app's sound is clean!

How do you check the CPU usage? Neither top nor uptime shows total CPU 
consumption or load average.

Anyway, no process in 'top' shows more than 0% CPU, and there are no messages 
from the dalvik garbage collector in the log that would coincide with the 
choppy sound.

[Regis, do you want to reopen this issue? Now it does not show up as "starred 
by me" display]

Original comment by egcros...@gmail.com on 4 Mar 2011 at 8:13

[GoogleCodeExporter]

Original comment by r3gis...@gmail.com on 4 Mar 2011 at 10:13

• Changed state: Accepted

[GoogleCodeExporter]

I'm experiencing the same issue using the Gingerbread edition on an HTC desire 
CM7.

even scrolling down a list produces choppy sound. codec is g729.

Using Skype the behavior is different, the sound stays crystal clear and the 
scrolling gets choppy.

Is this an issue of CPU priority ? I wish Csipsimple can be like Skype (on this 
issue (: )      

Original comment by alongold...@gmail.com on 23 Apr 2011 at 6:27

[GoogleCodeExporter]

Well, after a lot of research on this issue, I found something really 
interesting.

CSipSimple was setting thread priority using the native standard posix thread 
API. The native standard way. But after a closer look on android source code, 
it seems that android does not only use this to decide whether a thread is 
important or not.
The android scheduler (actually the linux one + some stuff from android), also 
manage thread groups. And when I was changing the thread priority the group of 
the thread was left unchanged. 

As consequence the thread was set with a very high priority but not in a good 
group. I guess that on some device it had a big impact and on other device 
where the thread grouping impact less the way the scheduler manage it, it had a 
lower impact.

So, I did the change in the revision 859 for the trunk nightly to use the java 
API instead of the native API (the java API should do every things hidden by 
the android OS, included the group change).

If some can test it and let me know how it goes :
http://nightlies.csipsimple.com/trunk/

Original comment by r3gis...@gmail.com on 15 May 2011 at 10:11

[GoogleCodeExporter]

r860/ginger on HTC Desire / Oxygen 2.1.1 (Android 2.3.4) - no more choppy sound!

Original comment by egcros...@gmail.com on 16 May 2011 at 6:47

[GoogleCodeExporter]

Just to be sure, by ginger, you mean the r860 trunk running the android OS 
gingerbread, isn't it? (cause the fix is yet not applied to the ginger edition 
of CSipSimple that use the openSL driver). I have to do so :)

Excellent news. It would mean that previous performance of pjsip audio were 
done without the good thread priority ;).

Original comment by r3gis...@gmail.com on 16 May 2011 at 8:53

• Changed state: NextRelease

[GoogleCodeExporter]

Sorry for the confusion. That was ginger branch, and I did not check thoroughly 
enough. After rechecking, the choppy sound did *not* disappear. I've installed 
r680/trunk now, and the sound is still choppy in it too.

Original comment by egcros...@gmail.com on 16 May 2011 at 9:13

[GoogleCodeExporter]

I don't know if this is relevant, just noticed in the log:

W/PackageManager(  124): Not granting permission 
android.permission.CALL_PRIVILEGED to package com.csipsimple (protectionLevel=3 
flags=0x83e46)
W/PackageManager(  124): Unknown permission 
android.permission.RAISED_THREAD_PRIORITY in package com.csipsimple

Original comment by egcros...@gmail.com on 20 May 2011 at 9:17

[GoogleCodeExporter]

The RAISED_THREAD_PRIORITY permission is something I tried times ago and that 
is maybe not anymore required. I guess that was valid as a private API of older 
android versions.

CALL_PRIVILEDGED is only for specific cases and that's not hurting to not get 
this priviledge. 
So that's expected warning ;). 

I think I've still a lot of things to learn on android thread priorities, it's 
much more complex that what I thought. So I'll continue my learning on this 
point and try to apply what I find to the app :).

Original comment by r3gis...@gmail.com on 20 May 2011 at 9:31

• Changed state: Accepted

[GoogleCodeExporter]

Issue 1329 has been merged into this issue.

Original comment by r3gis...@gmail.com on 7 Nov 2011 at 12:33

[GoogleCodeExporter]

Just tried to reproduce with r1146 (non-ginger) and the sound is smooth, no 
chopping when I run other activities. Android 2.3.7 (Oxygen 2.3.2).

Original comment by egcros...@gmail.com on 26 Nov 2011 at 10:06

[GoogleCodeExporter]

Same here, no chopiness even when installing/updating other apps, much more 
improved since 2.x

Original comment by hotplug...@gmail.com on 29 Nov 2011 at 6:39