[linux-dvb] Revisiting the SNR/Strength issue
devin.heitmueller at gmail.com
Thu Oct 16 16:28:04 CEST 2008
On Wed, Oct 15, 2008 at 2:18 PM, Steven Toth <stoth at linuxtv.org> 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
> 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
Devin J. Heitmueller
More information about the linux-dvb