Rusty Scott wrote:
Having parsed through a number of the comments on this thread and feeling that
many of the responses have missed the mark. Here is my bottom line:
1) If the only thing the end user wants is signal strength and quality then why
doesn't the API only support these calls? Let the driver developer decide how
these are measured for a given card. Value is 0 to 100% for both strength and
quality. (Sounds absurd when taken to extreme)
2) Why not return BER or UCB in values from 0 to 100%? The user is really only
concerned about if these are high or low. They don't care about any absolute
number.
3) If SNR is useless in determining signal quality why have the capability in
the API at all? If the capability is there to read SNR then it should be SNR
and since the driver is where chip specific information is stored, the driver
should know how to put that number into dB because it is different for
different chips. If a card doesn't have the capability to actually determine
SNR then it shouldn't be returning one. It should have other parameters to help
determine signal quality.
Hmm.. you didn't follow the issue with the scale in dB. The issue is
that the demod (which the driver driver names itself as) doesn't do any
conversion statistics. For example suppose you have a STV0299 demod
based tuner from vendor A. vendor A will provide additional RF hardware,
which will alter the input RF parameters of the tuner.
Now vendor B will think that he stick to the reference design. Vendor C
will think both these guys are off track, and he will provide another
alternate solution.
In this case, the parameters in all these cases are different.
Coming back to square one, what we thought was that instead of having
just demod definitions alone, we will have tuner definitions too, we
have access to information about many devices, but the current API case
has limitations, such that we cannot fit it in.
In this aspect what we decided was that we will go to a standstill with
the current API, since the new changes will anyway break compatibility
for sure. In such a case, what we decided was that we will get all the
required changes and make one change as to break the API for once,
rather than multiple times.
and hence the situation.
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
