RE: [GnomeMeeting-list] Audio delay compared to netmeeting.

["Mike Visser" <mikev powerquality co za>]

If you are getting a reflection (?) of the mic input that much later (1
to 2s) then possible some or other rotating buffer is overflowing
infrequently to dynamic pointers cyling through their rounds (buffer
memory allocations), giving rise to the input (mic) output (speakers)
subtraction algorithms installed to prevent distortion in the first
place resuperimposing the memory block into the output stream? try a
different mic?.  Somewhere some memory routine is thinking it is larger
at some times than others, and the dynamism is not syncing properly.
Hope my ?c helps.
Mike  


-----Original Message-----
From: powerqua bahamas eshockhost com
[mailto:powerqua bahamas eshockhost com] On Behalf Of Bruno Hertz
Sent: 07 December 2004 08:10 PM
To: gnomemeeting-list gnome org
Subject: [GnomeMeeting-list] Audio delay compared to netmeeting.


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.


_______________________________________________
GnomeMeeting-list mailing list
GnomeMeeting-list gnome org
http://mail.gnome.org/mailman/listinfo/gnomemeeting-list