High CPU load in audio conference application

Question

Hi Java Guys and Java Girls.
We are developing an audio conferencing application that is based on the AVTransmit and AVReceive examples, from the JMF 'code samples' page: http://java.sun.com/products/java-media/jmf/2.1.1/solutions/AVTransmit.html
The main change that we made to the examples was to spilt the application in to two threads, one which receives and one which transmits, in order to use the duplexing capabilities of our shiny new (and expensive :-) sound cards - M-Audio Delta 44.
Our problem is one of performance. Even when only one of the channels is working, we get a lag of somewhere around 1 second. When both channels are connected and running, the CPU load jumps up to 100%, and the streaming breaks down in both directions. With only one of the 2 channels open the CPU load is only about 1% - below the tolerance of the measurement.
Interestingly enough, we tried running the UI Example as well, using 2 different TCP ports to get duplexing running between the 2 computers, and we encountered the same problem.
We've been bashing away at this problem for weeks now, and we have tried all sorts of things, but now we are rapidly reaching the edge of sanity. We really need to get this to work, with lag times below 0.25 seconds, and without taxing the CPUs too much.
We would be extremely grateful if you could look at the code that we are pasting below, and let us know if you can see what we are doing wrong.
Thanks very much for your help.
Yours,
Adam Crowther
Martin Piwowarski
PS We are using 2 Athlon 2.0+ Systems, each with 512MB of RAM, running Windows XP Pro, and streaming over a 100MBPs Ethernet LAN, using the on-board LAN adapters.
PPS We put the code here:
http://www.adamcc.ch/jmf/

Answer 1

The problem is not your code, but the stock JMF DirectSound audio renderer.
The audio renderer has its DirectAudio buffer hard-coded to hold 2 seconds of sound. Therefore, if you have any lag for any reason from the audio card driver when sound is starting up, you will have an audio delay of up to two seconds.
My company had to make heavy modifications to the original JMF audio renderer. We set up a 300 millisecond buffer and also introduced code to handle buffer starvation, etc., etc. I would suggest you get the JMF source code and check this out for yourself.
Good luck.