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
