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

[Manu Abraham]

Daniel Kristjansson wrote:
> 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.
>   

The issue is not on the code. Imagine if MythTV guys have a big issue in 
for a small code change to make it alright, imagine Linux kernel !

> 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
>   

For the ideal driver, things are explained here ..
http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-apps/util/szap/README?rev=1.4&view=markup

> 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.
>   

Currently it is not in dbuv, since there are no log functions used to 
compute it. It is ATM a value which is "conveniently" mapped to an 
existing range. But don't expect things to remain the same.

> 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.
>
>   

Sometimes a small delay can make a difference between life and death.
> 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.
>   


It is not the API that is non-informative, but certain things can't be 
done as it is , just like that in kernel drivers.
The reason being different hardware vendors do the same thing in 
different ways.


> 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.
>
>   

I don't think this can be done at all.

> 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.
>
>   

Once you have a FE_HAS_LOCK, you can read the dvb_frontend_parameters

> 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.
>   

Hmm.. some hardware doesn't work as you expect. For the ideal hardware 
yes, one should be able to query etc.

> 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.
>   


The features what you are asking for are in the TODO list for the 
library. The library will even have card specific information and PCI 
ID's *if* all goes well.


Manu