New USB-Statistics API

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

 



Hello together,

after the last thread which asked about signal statistics details degenerated into a discussion about the technical possibilites for implementing an entirely new API, which lead to nothing so far, I wanted to open a new thread to bring this forward. Maybe some more people can give their votes for the different options

Actually Manu did propose a new API for fetching enhanced statistics. It uses new IOCTL to directly fetch the statistical data in one go from the frontend. This propose was so far rejected by Mauro who wants to use the S2API get/set calls instead.

Now to give everyone a quick overview about the advantages and disadvantages of both approaches I will try to summarize it up:

1st approach: Introduce new IOCTL

Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
1. all values are fetched in one go (as long as possible) from the frontend, so that they can be treated as one united and be valued in conjunction 2. the requested values arrive the caller in an almost constant timeframe, as the ioctl is directly executed by the driver - It does not interfere with the existing statistics API, which has to be kept alive as it is in use for a long time already. (unifying it's data is not the approach of this new API)

Cons:
- Forces the application developers to interact with two APIs. The S2API for tuning on the one hand and the Statistics API for reading signal values on the other hand.

2nd approach: Set up S2API calls for reading statistics

Pros:
- Continous unification of the linuxtv API, allowing all calls to be made through one API. -> easy for application developers

Cons:
- Due to the key/value pairs used for S2API getters the statistical values can't be read as a unique block, so we loose the guarantee, that all of the values can be treatend as one unit expressing the signals state at a concrete time. - Due to the general architecture of the S2API the delay between requesting and receiving the actual data could become too big to allow realtime interpretation of the data (as it is needed for applications like satellite finders, etc.)

I hope that this summary is technically correct in all points, if not I'd be thankful for objective corrections. I am not going to articulate my personal opinion in this mail, but I will do it in another mail in reply to this one, so that this mail can be seen as a neutral summary of the current situation.

So now it's everyones turn to think about the options and give an opinion. In the end I am quite sure that all of us would have great benefits of an improved statistics API.

Cheers,
Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux