Re: [Ekiga-list] audio lag on 2.0.11

["Bruno Hertz" <brrhtz yahoo de>]

Palo S. <palos post sk> 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.