Re: [linux-media] Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>]

On 17.01.2013 18:22, Antti Palosaari wrote:
> On 01/17/2013 07:16 PM, Manu Abraham wrote:
>> On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari <crope@iki.fi> wrote:
>>> On 01/17/2013 05:40 AM, Manu Abraham wrote:
>>>> MB86A20 is not the only demodulator driver with the Linux DVB.
>>>> And not all devices can output in dB scale proposed by you, But any device
>>>> output can be scaled in a relative way. So I don't see any reason why
>>>> userspace has to deal with cumbersome controls to deal with redundant
>>>> statistics, which is nonsense.
>>>
>>>
>>> What goes to these units in general, dB conversion is done by the driver
>>> about always. It is quite hard or even impossible to find out that formula
>>> unless you has adjustable test signal generator.
>>>
>>> Also we could not offer always dBm as signal strength. This comes to fact
>>> that only recent silicon RF-tuners are able to provide RF strength. More
>>> traditionally that estimation is done by demod from IF/RF AGC, which leads
>>> very, very, rough estimation.
>>
>> What I am saying is that, rather than sticking to a dB scale, it would be
>> better to fit it into a relative scale, ie loose dB altogether and use only the
>> relative scale. With that approach any device can be fit into that convention.
>> Even with an unknown device, it makes it pretty easy for anyone to fit
>> into that
>> scale. All you need is a few trial runs to get maxima/minima. When there
>> exists only a single convention that is simple, it makes it more easier for
>> people to stick to that convention, rather than for people to not support it.
>
> That is true. I don't have really clear opinion whether to force all to one scale, or return dBm those which could and that dummy scale for the others. Maybe I will still vote for both relative and dBm.
>
> Shortly there is two possibilities:
> 1) support only relative scale
> 2) support both dBm and relative scale (with dBm priority)
>
> [3) support only dBm is not possible]

4) support relative scale (mandatory!) and dBm (if applicable).

I concur with Antti. Any device's values can be made to fit into
a 0..100 (or whatever) range, so *that* should be the primary (and
mandatory) value. If the device can do so, it can also provide a dB*
value (replace * with anything you like, 'm', 'uV', 'uW', whatever)
and maybe all other sorts of bells and whistles.
So real world applications could simply and savely use the relative
value (which is all they need), and special applications could fiddle
around with dB values (provided the device in use can deliver them).

@Mauro: here's some further reading for you, just in case ;-)

   http://en.wikipedia.org/wiki/KISS_principle
   http://www.inspireux.com/2008/07/14/a-designer-achieves-perfection-when-there-is-nothing-left-to-take-away

Klaus