[Bug 768110] new plugin: ahssrc (Android hardware sensor source)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=768110

--- Comment #4 from Martin Kelly <martin at surround.io> ---
Thanks for all the comments!  It seems like the main aspect of this to figure
out is the clocking and the messages vs buffers. Once we agree on the right
solution forward there, I will release an updated patch addressing all the
comments.

The reason why I created the optional "emit-events" (I'll change it to
"emit-messages") is that, currently, there is no sink for handling sensor data.
Thus sending messages out on the event bus is what I'm currently using for
getting the sensor data and for debugging it. Once a sensor sink exists, this
property should probably be dropped, as the sink could do a better job.

Because messages are not synchronized nicely with buffers, I gave them system
time rather than pipeline time, as an app processing the events doesn't know
how to handle pipeline time. I could instead just use pipeline time for the
messages, but then the app would have to somehow translate to system time. My
intention was to keep the buffers using the pipeline clock, so please let me
know if you noticed a bug and that's not what's happening. Thus the current
division is:

- messages use system time so that apps can understand them out-of-band with
the pipeline
- buffers use pipeline (GST_ELEMENT_CLOCK) time so they're synchronized with
the pipeline

Now, it's true that Android supplies a timestamp in the SensorEvent object as
part of the sensor data callback. Last time I checked, this was monotically
increasing time since Android system boot. Right now, I'm ignoring that
timestamp and just using the element clock when I receive the callback to
compute the buffer duration. However, you're right that it would be better to
use the timestamps given in the events and slave them to the element clock. I
will make that change.

It seems there's a few main issues to figure out:

- Should we keep the "emit-messages/emit-events" property? If we don't keep it,
there's no easy way to see these events until we add a sensor sink. If we do
keep it, then we have an inelegant out-of-band channel for events.
- If we keep the "emit-messages" property, should it use system time, or should
it use pipeline time and let the app convert to system time?
- Where should the headers for the sensor caps be exported, and what's the
correct way to handle that in Makefile.am?

Once we resolve these issues, I'll issue an updated patch. Thanks again for the
helpful feedback!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.