Re: DVB API update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 17, 2007 at 06:02:50PM +0200, Johannes Stezenbach wrote:
> On Sat, Sep 15, 2007, Wolfgang Wegner wrote:
> > 
> > - dvb_fe_type: DVB-S2 is missing and I personally would also like
> >   to see ASI here...
> 
> See my other mail, IMHO we should add the ASI defines at
> the same time we merge a driver which uses it.

Well, on the other hand this can prevent from others (hardware
vendors?) to have a deeper look into the linux-dvb api because
it does not even care about ASI.

Again, I think the "dummy" frontend approach from Manu could be a
viable solution, but you should have the possibility to add a basic
frontend with minimal status information (lock/no lock) without
much headache.

> > - frontend status:
> >   - BER is lacking a proper definition (to which base is it calculated?)
> >   - signal strength: same problem, what are the ranges?
> >   - snr: again, no base and ranges given
> 
> The original Nokia DVB API spec had proper definitions, but
> Holger Waechtler and me decided to drop them in favour of
> "read hw register and scale to range 0..0xffff". The reasons
> for this were:
> - for some hw we didn't have info to implement it properly
> - for those hw where we had info we saw it wasn't worth the
>   effort -- I believe the implementation in the demod firmware
>   is just such a coarse approximation that it doesn't
>   even make a difference if you take the logarithm or not
>   (provided you scale back into the 16bit range)
>   (of course you get different numbers, but none of them
>   maps any better to what you'd expect)
[...]

I do not have info about much hardware, all I can say is that
BER and SNR work quite good with STV0299, STV0288, TDA10046 and
TDA1002x. This is reason enough for me to raise the hand for
voting for an interface that at least gives the possibility
to implement this in the demod driver.
(I have to admit that you have to use some basic averaging, but
if this could be handled in some kind of frontend thread, I see
no problem. I will see how this can be implemented without floating
point calculation, because up to now this was done on another
platform where floating point was not an issue.)

The main reason to do this is because this is the only place
where it _can_ be done! The application accesses the demod through
the API and does not know anything about its registers or anything,
neither should it.

BTW, the "scale to range 0..0xffff" does not seem to be true for
all demods (at least this is what I remember), and at the very least,
this scale and direction (0 = best or worst?) should be clearly
stated in the API!

>From my point of view and taking into account your arguments, the
main problem is: how could one implement such an interface in a
backward-compatible manner and such that an application can see
if the demod it currently uses does return precise values (that
can be displayed as dB or something like that) or not, because
there may be demods where we really can not provide proper values
or that simply nobody had the time to look at yet.

Best regards,
Wolfgang


_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux