On Wed, Oct 15, 2008 at 2:18 PM, Steven Toth <stoth@xxxxxxxxxxx> wrote: > It will happen when someone cares enough to do it, that's the Linux mantra. I care enough to do it, but I'm trying to see if there's a solution that doesn't require me to learn the intimate details of how SNR is computed for every demodulator in the codebase (and then change that representation to dB). I think it's actually really important that regular users be able to use their application of choice (Kaffeine/MythTV/other) and be able to tell whether they have a descent signal without having to look at the kernel driver source code for the demodulator that is in their tuner (that sentence alone has six words most regular users couldn't even define). > Let's quantify this. How many frontends would have to change? I didn't get a chance to do a count last night. I will do this tonight when I get home. >> engineering would have to be done, and in many cases without a signal >> generator this would be very difficult. This could take months or >> years, or might never happen. > > You don't need a signal generator, you _do_ need a comparison product that > is reliably reporting db. > >> >> Certainly I'm in favor of expressing that there is a preferred unit >> that new frontends should use (whether that be ESNO or db), but the >> solution I'm suggesting would allow the field to become useful *now*. >> This would hold us over until all the other frontends are converted to >> db (which I have doubts will ever actually happen). > > I'm not in favour of this. > > I'd rather see a single unit of measure agreed up, and each respective > maintainer go back and perform the necessary code changes. I'm speaking as a > developer of eight (?) different demod drivers in the kernel. That's no > small task, but I'd happily conform if I could. > > Lastly, for the sake of this discussion, assuming that db is agreed upon, if > the driver cannot successfully delivery SNR in terms of db then the bogus > function returning junk should be removed. > > Those two changes alone would be a better long term approach, I think. I'll see tonight how many demods we're talking about. Certainly in the long term I agree that this would be a better approach - I'm just concerned that "long term" could mean "never", in which case I don't think it would not be unreasonable to have a less-than-perfect solution. Cheers, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
