Re: [Speak-freely-devel] Re: Feature removal proposal

On Sun, Apr 18, 2004 at 02:28:22PM -0400, Jeffrey S MacKinnon wrote:

> The "increasing delay" problem addressed by the "Output Rate
> Adjustment" feature in 7.6 was caused by the inevitable slight
> difference in sound card (or system) clock rates between the two
> users.  If the receiver's clock runs slower than the sender's clock,
> than significant delays build up over a period of time.  This the
> problem that I was experiencing with certain other users (depending
> on our clock rate differences) - and this was the problem for which
> John's fix compensated.  With certain users, I would see delays of
> up to 10 or 20 seconds or more after just a few minutes of
> transmission.  Prior to the rate adjustment fix, the only workaround
> was for the sender to periodically stop transmitting until the
> receiver's output queue caught up (emptied).

This is one component that can cause delay, and the only one that will
grow without bound.  10 seconds over a few minutes seems excessive
though, as audio cards should be more accurate than that.  

> This problem was not related to network delays or reliability, nor
> any other actual delays (buffer or otherwise) at either end.  If you
> had an ideal network with "0" delay for every packet, and "0" delays
> at both ends, then this problem would still exist if the receiver's
> clock ran even a little bit slower than the sender's clock.

> It seems to me that your (Soren) method will solve this problem (as
> well as many others).  Am I correct in this interpretation?

It should be at least as good as 7.6 in doing that.  The only area it
may break down in is that it uses a history of packet arrival times to
choose audio play times.  That history is currently about 25 seconds.
If there is significant clock rate error over that 25 second period,
then there may be a slightly higher than designed-for loss of late
packets if the far end is transmitting slowly.  Alternatively, if the
far end is sending too quickly,  then there could be as much delay as
builds up over the 25s. I would expect less than 1% error though
(250ms), or someone should be taking the faulty audio card back.
Otherwise it suggests we should monitor the sample rate and resample
if it isn't what we set the audio hardware to.  I'd want to see a case
of real problems before adding extra estimation though, because the
more things you try to estimate, generally the harder it fails if
something goes wrong.  


Soren


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click