wk wrote: > Andreas Oberritter wrote: >> If you find two devices which need different inversion settings in the >> same network, then it's a driver bug, which can easily be corrected. >> >> > How can this be a drivers bug, if in the dvb api documentation no > *default value* for inversion was ever defined? > Seems to be a bug inside API (linux-dvb-api-1.0.0.pdf, see > http://www.linuxtv.org/docs.php). Common sense says that the default value is not inverted. >> Spectral inversion depends on the transmitter, too. It can change >> anytime a broadcaster decides to change it. It happens, although not >> very often. >> >> Specifying the inversion parameter can speed up the tuning process, >> especially for devices which don't support automatic swapping in >> hardware. But I would not recommend to store this parameter in a service >> list. >> >> If we decide to keep the parameter, we should probably use four options: >> INVERSION_OFF, INVERSION_ON, INVERSION_AUTO_OFF_FIRST, >> INVERSION_AUTO_ON_FIRST, which matches the capabilities of most >> demodulators. A typical application would then probably use only the >> last two options, while the first two options would rather be used for >> diagnostics and to read back the detected inversion. >> >> >> > May be. But since the application cannot get any information about > transmitters inversion only AUTO makes sense here, neither ON or OFF. > No information field is reserved for inversion inside terrestrial > delivery system descriptor and cable delivery system descriptor, > so applications are not able to figure out useful settings from NIT. > Please try to see this from the application side, not from hardware > point of view. Well, that's essentially what I wrote: Use AUTO in a typical application. All frontend devices support it, either in software or in hardware. Regards, Andreas _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
