[mythtv] [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T).

[Daniel Kristjansson]

On Thu, 2006-03-16 at 20:35 +0400, Manu Abraham wrote:
> Daniel Kristjansson wrote:
> > Yup, the averaging is in my long term todo, it just doesn't have a
> > terribly high priority because it doesn't serve any purpose in MythTV
> > yet. Many cards don't even report these values.
> You are right, we are looking at this aspect, but this involves some 
> changes like getting math operations into kernel/moving frontend drivers 
> out to userspace. We have some thoughts on this, but don't bet on it, 
> since there are quite some issues to be considered.
You can do this in the drivers with a short fixed point math macros.
Google "fixed point arithmetic", probably most of the stuff you will
find will be from a computer graphics viewpoint, so sq, sqrt, and divide
will be the most documented, but implementations abound other functions.

> Another one of the reasons why drivers are in such a state is that many 
> drivers are Reverse Engineered , since vendors don't release 
> specifications / information on them. But for some of them due to 
> certain reasons some things cannot be implemented in kernel as it is.
I understand that, I give the drivers a lot of leeway for not
normalizing the signal to noise ratio, etc. I'm more concerned
that the DVB API doesn't specify what one should expect with
the ideal driver. For instance, for the signal to noise ratio to
have any accuracy the signal has to be multiplied by something.
Or it has to be in decibels, and even that would have to have a
fixed point or the only values you would ever see are 0, 1, 2 or 3.

> We are looking at userspace libraries to fix issues like this, so that 
> all such information like this can be contained in them such that 
> applications  do not have to be bothered by issues like this. It will 
> not be too long for them.
That would be nice :)

> Hmm.. I was talking to Ralph Metzler, he told me that Marcus Metzler 
> sent you guys a patch to fix the issue properly. If Marcus sends you a 
> patch i can assure you that you that you can use that patch as it is.
It turns out I already switched to something like this, the only
difference is the delay I used was shorter. This works with many
more drivers than the old code. But I then added the wait_for_backend
function in addition to this loop, which made even more drivers work,
but we still have problems.

> > The well coded drivers mostly used the safe 0..2^15 range anyway, so
> > it looks like all cards are reporting somewhat sane values now.
> AFAIK, the values are simply mapped and on different hardware it has 
> different meanings. It might need further processing to display 
> something really sane enough.
I don't mind processing, but the processing should be the same for
each driver. But the API is still unclear on what these things should
return. Right now we report the signal value as percentage 0-100%
and report the S/N in dB after taking log10f on the value, but this
was arrived at through experimentation, the DVB API is non-informative.

> I understand what you are saying, but if you say that if you want 
> drivers to be fixed, then it would be as good as talking terms to the 
> kernel folks to have certain features in the kernel. So IMHO if you 
> think that things should remain broken for that period till LK folks 
> agree, then MythTV will remain broken for all those time.
All I want to know is when the driver has told the hardware to switch
to a new frequency and the hardware is no longer locked on the old
frequency.

If I were making a wish list I'd also want to know which frequency
we are locked to when we get an FE_LOCK, right now you can tune and
immediately see an FE_LOCK, but in fact it just means you either have
a lock on the old transport OR the new transport. You can query what
frequency you are on, and you will see the frequency you just tuned
to, but in fact the hardware is still tuned to the old frequency.

You can see why this can drive a driver user crazy? Also, I don't
really see this being due to the drivers being reverse engineered,
if the driver writer doesn't know how to query something from the
hardware he should figure out how long the hardware takes and return
some value other than FE_LOCK or the new frequency/old frequency
while this delay expires. That way the user space application can
use the same calls with drivers which do have this information as
with those which do not.

Even more wish listy, I'd also want to be able to query the
vendor name and backend name for the card in addition to the 
frontend name, I would also like multiple input cards like the
HD-2000 to have all their inputs supported so I could drop support
for the V4L digital driver for this card. For scanning, I would
like to be able to tell the driver to tune to a frequency and not
have the driver go looking for the closest working frequency,
though of course any PLL in the hardware shouldn't be disabled.

> IMHO you guys should adapt to something what's acceptable to the rest of 
> the world for the time being and later on use the stuff whatcomes out as 
> a good solution. First fix the immediate problem, then go for the finer 
> fix. Don't wait for the fine fix to be your first and final fix.
Yeah, I think I'll add some fixed delay to 0.19-fixes for the drivers
that need it, and hope for a better solution for 0.20.

-- Daniel