Manu Abraham schrieb
Not only is it time critical, but it should also be "atomic", ie it
should be all in one go, ie one single snapshot of an event, not
events bunched together serially. Things wont seem that "atomic" on a
system with a large load. Latency will have a significant effect on
the statistics (values) read back, since it is again disjoint events.
Right, the values should be treatened as a unique unit...
Time stamping would be helpful, prior to any processing by the library
such that the time overhead for the calculations is offset, but that
can be really useful within the same library alone. I can't imagine
how time stamping can be helpful to result a low latency.

No, timestamping would of course not be helpful for reducing the latency, it would just allow to correctly interpret values if they are delayed. So that you won't assume the values you receive can be taken as proven for the current moment.

If you don't have a low latency, Consider this (even when you are able
to ignore the statistics for any general processing, on the thought
that "i can always live with those errors and i always had"):

The error fedback into the loop for a sat positioner/rotor. The final
calculated position will never be the actual position that you wanted
the antenna to be at a certain location. The problem would be made
worser by the different rotor speeds as well, to add to the nightmare.

With the V5 operation, you bunch operations together in a serial
manner, it is atomic to the sense that it happens or doesn't happen,
but it is not atomic to the sense of any particular time frame. You
just keep your fingers crossed that the CPU executes the event in the
shortest frame. This won't hold good in all cases when there is a high
latency on the system when there is a significant load.

eg: You can imagine an IPTV headend streaming data, with a small CPU
with multiple tuners and trying to compensate the offset that's

Still worser situation: imagine a gyro stabilized setup, where the
base itself is not that stationary.

Ok, thanks for the details about how V5 API deals with this. Indeed this is a major issue one has to think of when talking about signal statistics.

Some other points to be considered:
* As of now, the get/set interface is not used for any signal statistics

* Even if one prefers to normalize all parameters into one single
standard, even then you wouldn't land with a get/set interface.

* The generic get/set interface is good when you have an unknown set
of parameters, such that one can keep adding in parameters.  Eg: most
people favoured this approach when we had a larger set of modulations/
error correction and other parameters.

For the case what we have currently, we do not have such a varied set
of parameters to consider.

Right, the situation about the parameters which will be requested in terms of signal statistics should not change for future frontend types, so it really should be a save approach to have a static API here. I have not yet done a very detailed look into your proposed patch, but I will do so tomorrow.
I really would like to see a reliable statistics API in v4l-dvb soon.

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to
More majordomo info at

Reply via email to