Palo S. <[EMAIL PROTECTED]> writes: > Indeed, I can confirm this regression. I blamed my new provider > for this increased lag problem but now I have tried downgrading > to 2.0.9 and indeed, the lag is significantly smaller. Possibly > important difference in -d4 logs between 2.0.9 and 2.0.11: > > 2.0.11: > Media Audio sink data size set to 320 bytes and 20 buffers. > > 2.0.9: > Media Audio sink data size set to 320 bytes and 3 buffers.
As a general sidenote, I can tell you that a couple of years ago I spent weeks evaluating several SIP clients due to lagging issues until I found out how much this may depend on buffer/fragment/period numbers and sizes, depending of course also on the driver, card, the current driver implementation and various libraries (alsa etc) sitting in between. In fact, at that particular point the driver/libraries and suboptimal application defaults regarding sound caused much more lag than the network transmission proper on my system. The whole issue is really a drag, and it's a pity linux sound architecture designs offer no provisions for timing guarantees or at least delay measurement aids for interactive use cases like VoIP. The whole thing basically stinks, imho. If it was possible to implement some kind of network round trip time measurement in ekiga debug/verbose mode, I guess that might help pinning down lagging issues much more easily. Maybe there's even some facility defined in SIP, you guys will know. Regards, Bruno. _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
