From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from racoon.tvdr.de ([188.40.50.18]:38108 "EHLO racoon.tvdr.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754221Ab3AQRjZ (ORCPT ); Thu, 17 Jan 2013 12:39:25 -0500 Received: from dolphin.tvdr.de (dolphin.tvdr.de [192.168.100.2]) by racoon.tvdr.de (8.14.5/8.14.5) with ESMTP id r0HHdOvc009596 for ; Thu, 17 Jan 2013 18:39:24 +0100 Received: from [192.168.100.11] (falcon.tvdr.de [192.168.100.11]) by dolphin.tvdr.de (8.14.4/8.14.4) with ESMTP id r0HHdIo8013488 for ; Thu, 17 Jan 2013 18:39:18 +0100 Message-ID: <50F83746.8020409@tvdr.de> Date: Thu, 17 Jan 2013 18:39:18 +0100 From: Klaus Schmidinger MIME-Version: 1.0 To: linux-media@vger.kernel.org Subject: Re: [linux-media] Re: [linux-media] Re: [PATCH RFCv10 00/15] DVB QoS statistics API References: <1358217061-14982-1-git-send-email-mchehab@redhat.com> <20130116152151.5461221c@redhat.com> <2817386.vHx2V41lNt@f17simon> <20130116200153.3ec3ee7d@redhat.com> <50F7C57A.6090703@iki.fi> <50F8333E.2020904@iki.fi> <50F836CE.2020502@tvdr.de> In-Reply-To: <50F836CE.2020502@tvdr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On 17.01.2013 18:37, Klaus Schmidinger wrote: > 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 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. Sorry, that should have been "Manu" - got the wrong quote level... > 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