[GnomeMeeting-list] Audio delay compared to netmeeting.

[Bruno Hertz <brrhtz yahoo de>]

Hi folks

on trying out gnomemeeting on my LAN, initially to figure
out firewall issues, I noticed that with gm <-> netmeeting
LAN connections the audio lag is considerably higher in
gm -> nm direction than the other way round, amounting to
1 to 2 secs delay.

In an attempt to track that issue down, I first tried
XP/nm on my linux box to find out wether the hardware
might be the problem. But the resulting nm <-> nm test
showed that XP/nm still performs much better on my Linux
box than FC3/gm with Alsa (soundchip is Ensoniq AudioPCI).

Then, I made some (naive) tests to figure out wether the
mic input is somehow delayed, of the kind arecord | aplay
resp. cat /dev/dsp > /dev/dsp. It turned out that I
heard mic input as well with 1 to 2 secs delay, so I wrote
to the Alsa list about this issue. There I was told that
the delay is due to buffering, and I should try running
arecord with various --buffer-size values. I did, and
with small values (up to 1024) the delay actually is
close to none. Of course, with small buffers I got crackling
sound, but still. The --buffer-size option apparantly does
not only effect the application level read buffer but rather
some hw parm buffer I don't know about, but I now understand
can and probably should be optimized according to the applications
requirements.

Now, finally my question :) Is there any way to optimize gm for
minimum lag with alsa, maybe by fiddling with the sources?
The only configurable option I've seen so far is the jitter
buffer, which I understand only affects incoming packets and
consequently wouldn't help in this case. Or is gm already attempting
to optimize and is the current performance the best I can get?

Hints highly appreciated, Bruno.