[linux-dvb] Improving recovery in the frontend tuning thread

[Jon Burgess]

While reading through the frontend tuning thread code I noticed that the 
algorithm in update_delay() looks wrong. The code doesn't have any 
comments in it to indicate what it is intended to do, but the way I read 
it, the intention is to slow down the scanning if we've recently locked 
and make it faster when we've not locked for a while.

Here is the piece of the code in question:

static void update_delay(int *quality, int *delay, int min_delay, int 
locked)
{
     int q2;

     if (locked)
	      (*quality) = (*quality * 220 + 36*256) / 256;
     else
	      (*quality) = (*quality * 220 + 0) / 256;

     q2 = *quality - 128;
     q2 *= q2;
     *delay = min_delay + q2 * HZ / (128*128);
}


The quality value slowly increases when we lock and drops when unlocked.

The code does the right thing if the quality level is > 128, by 
returning an increasing delay as the quality increases (i.e. more delay 
when we are locked most of the time).

What I think is wrong is that as the quality goes below 128 the delay 
also starts to increase! This is because q2 goes negative and so q2*q2 
is positive and increases as quality goes to zero. If we never get a 
lock then the delay is just as long as if we have a near perfect lock.

I reckon the behaviour needs to be adjusted as per this patch so that 
the code returns "min_delay" for all values of quality < 128. It should 
help recover more quickly if the signal has been unlocked for a long time.

Does this make things better?
Or is the large delay when the quality is near zero intentional?

	Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvb-fe-delay.patch
Type: text/x-patch
Size: 483 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20050902/66aec8b2/dvb-fe-delay.bin