Le Thursday 16 October 2008 16:28:04 Devin Heitmueller, vous avez écrit : > 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). Have to add that most users even don't know what "dB" is. So, whatever the unit, an application would have to translate it in an understandable form, which could be as simple as : "Very bad signal quality" "Bad signal quality" "Good signal quality" "Very good signal quality" > > 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". Yep it could, seeing how much time this issue has been discussed and still no solution. -- Christophe Thommeret _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
