On Tue, Mar 24, 2009 at 4:46 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote: >>> From the end user point of view it is not very usefull if he has 2 >> different cards and application can not show any usefull signal goodness >> info in a way that would be easy to compare. So I think the attempt to >> standardize to db is good. > > The first part: For comparison having a standardized value is good. > > True. > > But the problem that surrounds it: > > To do this, a driver should support statistics in dB. For a device > which doesn't show statistics in dB, for reasons > (a) device uses a different format > > (b) enough information is not available to do a conversion > (too less information, or a reverse engineered driver) > > (c) the conversion to be done makes things too complex in kernel land. > > So you have very less devices to do a comparison between. Those are strong points you're making and more then enough reason to maintain the values in their native form and deal with it elsewhere. > The other way to do this: > > Suppose, the driver that doesn't support a dB format (relative > doesn't mean unknown) provides the information in a relative format. > And the driver that provides the information in dB format, but that > information you get, can be converted in to a relative floor - > ceiling format (conversion handled by application, or by a library) > > This is a quick way. > > Now, which all devices do provide a scale in dB, which is really > comparable ? There are many different parameters, quickly hacked > together to be called SNR. In the terms you mention, you will be > comparing things like > > SNR to CNR etc based on the device type. > > So eventually your comparison is wrong. Another good point. And a quick comment that I like the idea of a library. This takes the burden off the app while leaving options available instead of just forcing everything to dB whether it's compatible or not. >> Maybe there could then in addition be some other optional method for >> also getting data in some hw specific format in a way that Manu suggested. >> But there should anyway be mandatory to have this one "standard goodness >> value" in a way that does not require apps to make any complicate >> comparisons... (I bet half of those apps would be broken for years) > > In the way i mentioned, it leaves to the application to choose from > different styles such as > > (1) display parameters from the drivers, in their own native format > (This is a completely human readable format, in which you can see > the real scales) > > (2) convert parameters to a specific format. > (The very important part here is that the application is free to > convert from format A with driver X and format B with driver Y, to > get it into a unified format. if you really need the feature what > you mentioned, you need this feature, rather than have all drivers > being modified to provide one standard format) > > To make things look simple, i have a sample application which does > (1) to make things look simple. > > If you choose to do (2) It will be just doing the conversion one > time in a library or application, once rather than doing it multiple > times in unknown ways and formats. Makes sense. One of my concerns was that this would just be slapped together and rushed like some other things were and finding out how bad of an idea that was after the fact. This doesn't need to take forever to reach a majority opinion, but it should have enough thought behind it to not cut people off at the knees. It sounds to me that preserving the native format is certainly a good idea for the numerous reasons that have been pointed out, and providing converting via library is the most sane approach. Trying to force a square into a circle never seems to work out very well. Best regards, Derek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
