[linux-dvb] Re: AVerMedia 771 problems [everything solved]

[Christopher Pascoe <c.pascoe@itee.uq.edu.au>]

On Tue, 29 Jun 2004, Nathan Hand wrote:

> > If the frontend (not the driver!) is smart enough to correct wrong
> > parameters, why shouldn't it do so? IMHO what counts for most people
> > is that they can watch TV ;-)
>
> I thought my point was clear, but I will try again.
>
> The problem is when the frontend corrects the values and GETS IT WRONG.

The patch that I proposed about 16 hours ago turns off all automatic
parameter searching when one explicitly specifies all parameters which, I
believe, is what you are after.  It should work for the most case where
one know parameters, but still lets one set FEC_AUTO, etc, when they
don't know what's going on.

> Imagine if write(2) corrected your spelling. It's a horrible idea.

Providing that you have the guard interval and transmission mode set
right, ETSI 300 744 suggests that you should be able to use the TPS
information - and, it is error-corrected OTA too, so should be "as the
broadcaster intended".  If the broadcaster is sending the wrong values for
these, I would expect many more problems to emerge with everyone's STB's,
etc, that do use these parameters.  That should mean it will get fixed
rather quickly if it is ever set incorrectly - have you seen cases where
the broadcaster is sending the wrong thing?

So, whilst write(2) can't reliably correct your spelling, and shouldn't
try to, the mt352 frontend/demodulator IC *is* in a position to make a
decision should things change.  It has the distinct advantage that it is
being told repetitively by the broadcaster what the right "spelling" is,
in the TPS information.  Where the MT352 goes beyond the standard is that
it provides functionality beyond that in the spec to let it quickly try
different guard and mode settings to let it acquire the TPS information in
the first place.

(The device driver isn't necessarily privy to this information and (I
agree with Johannes) should generally stay out of it beyond directing the
frontend hardware to do its thing.  That the driver shouldn't itself do a
search for parameters is easily demonstrated by supposing the extreme
case, where the broadcaster switches back and forth between two FEC
settings every few superframes.  There is no way that the driver could
expect to keep up, whereas the frontend hardware can track it without loss
of lock, as it's told in the TPS information what the new settings will be
and the exact moment the change should take place.)

Chris
-- 
Christopher Pascoe
IT Infrastructure Manager
School of Information Technology and Electrical Engineering
The University of Queensland   Brisbane  QLD  4072  Australia
Web: http://www.itee.uq.edu.au/~chrisp