Conrad Beckert wrote, On 02/01/2011 08:57 PM (EEST):
Hallo Aleksandar,
I do extensive audio testing on different machines. In general, audio quality is excellent. The same is the case for the echo canceller.
Unfortunately there are these conditions, you write about. Sometimes both CPU usage and signal latency go up. The most obvious consequence then is the complete failure of the echo canceller (you normally do not realize signal latency in a production environment unless you interrupt your partner or vice versa)
Changing the JVM from OpenJDK to Sun JRE improves the situation dramatically. On OpenJDK turning on either camera or desktop streaming reproducabily triggers the latency / CPU usage surge.
I am trying sun java 1.6.0_22 already with no success. Openjdk is really
somehow unstable with sip-communicator.
Hard to say what's going on. Its obvious that turning off features brings others in the frontline of CPU usage.
I'm almost certain CPU usage is the problem because when I open/close
the DTMF window during call, the sound becomes worse. If I don't touch
anything distortions are less. At least in a few tries I think this is
the case.
I haven't used VirtualVM to look into the Java processes (nice to learn about that 
)
My observations suggest me, that the audio process has a somewhat lower priority over other processes (I wonder if you can adjust priorities within Java - some nice command for the VM.)
http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Thread.html
You can set thread priorities. But it should be done by the application
creating the threads. Other trickery would be harder to implement (for
example with the byteman project).
Also there are native threads involved - such as in the video encoding. (needless to say that video encoding is the big showstopper for audio - especially on weaker machines - video is always excellent while audio drops off or trails)
I know that JNI has some overhead but I believe what I experience is too
much to be inly that. I'm not using video.
Do you have any idea if with the JVM Scheduler, a Java process can interrupt a running native thread - or would the native thread have to collaborerate (such as in Windows 3.1 times)
Threads can be given priorities. See the API doc above. There are
particular points in code where thread can be stopped and control given
to another thread. A thread can receive interrupt but AFAIK this is not
used by the JAVA scheduler. Also when IO is involved, sometimes thread
could be stuck waiting for input. I don't think this is the case here
though.
That might be an explanation. What do you think?
I don't think there is such thing as native thread (although I believe
java threads are backed by real thread whatever the OS supports). Rather
there are native calls which can be performed by whatever java thread.
I'm not sure about portaudio. It is maybe also creating some threads
that are not managed by the JVM but live in the JVM process?
Anyways in this case I don't think this is a problem because I'm only
doing audio and it seems threads handling audio are not given enough
priority or work very inefficiently or both. Moreover I'm running on
dual-core so 2 threads can execute simultaneously.
Greetings - nice to feel less alone with my problems
I wonder what CPU usage are others seeing while talking. Could it be a
problem with some native libraries of my linux distribution?
···
Conrad