Thanks for the patch, could you please comment on my below design related
question.

ARM side
---------
1) Do you know if their is any open-source element which prints arm cpu load,
bps,fps information? I guess most of these information can be easily calculated
by writing a simple gst application program. e.g

2) Have you check if gst-tracelib can be used to compute fps/bps/arm cpu load
without making any modification ?

If we are able to compute fps/bps/cpu-load using above two methods then we
should consider using either of those approaches instead of adding everything in
element.

DSP side
---------
I like your approach to get dsp load and MemStat. But i think we should also
provide a call-back method very similar to &quot;identify or queue&quot;
elements - which can be used by application to query the dsp status (if needed).
E.g something like this

I'm considering a possible use case where someone may wish to write gstreamer
application to replace dvsdk demo. Current dvsdk demo displays all of these
information on OSD window and if possible then we should try to provide these
DSP status information with callback so that user can query and display on OSD
plane.

I do not know of any existing GStreamer element that provides this type of
information. There is a debug element we might want to look into - but for
gst-dmai testing instead of capturing performance data.

Enhancing gst-tracelib was my first choice. I contacted the author and asked
about a generalized registration / call back scheme so that element specific
data could also be added to the normal gst-tracelib captured information. This
is my long term direction. The author indicated that no such mechanism
currently exists or has been proposed before. He did say he liked the idea.

Allowing an application access to this information is intriguing. I hadn't that
of that use before. I could see adding worse case values as well.

The propose of the proposed dmaiperf element is to capture performance data so
we can track if gst-dmai is getting faster or slower with each release.

gsttidmaiperf.c line 45:
... g_quark_from_static_string(&quot;dmaienc-params&quot;)
Looks wrong and doesn't seem to be needed.

gsttidmaiperf.c line 246:
engineName = g_strdup(g_value_get_string(value))
I don't see a matching free.

gsttidmaiperf.c lines 184 and 186:
Perfance should be Performance

gsttidmaiperf.c lines 276 .. 279, 287..288
g_snprintf...
The output from dmaiperf will likely be parsed by some simple tools and dumped
into a spreadsheet or database. Please make the parsing trivial, like
key: value ; &lt;more key: value pairs&gt;

Now that I have written it, I see the entire set has one timestamp, and there
is mem_segment data for each mem_segment, so my format isn't very good either.
Maybe someone as a better suggestion. My objective is a simple command line
tool to pull the data into the test results spreadsheet.

1. In gst_dmaiperf_init function the value for dmaiperf-&gt;hDsp is
initialized to NULL twice. You can remove one of these initializations.

2. I don't see that you are tracking the ARM CPU load as well as the DSP CPU
load.

3. There is no property to turn off certain statistics. For example, if I want
to collect stats during an AVI decode I need to add this element to the video
and audio paths. In this case I would want to disable the report of the DSP
load and memstats in one of the instances so that I don't get duplicate
information.

4. Following up on what Todd said perhaps just printing the stats as a comma
seperated list would be easier to parse and feed into a spreadsheet.

Overall this looks good but I think we need to add items 2 and 3 above.

Sorry for the late review, Lix. I have the following comments, although they
are all minor:

1) A couple functions are missing comment blocks.
2) You use &quot;4096&quot; in a few places for a temporary string.
Static string-lengths always raise a red flag with me as I have debugged many
array-bound-write issues that root-caused to something like this. Given that
this is a debug element and time stamps have a fixed size, I'm not too alarmed,
but it would be good if we could do one of the following:
a. Find a way to calculate the max size of the string, and malloc/free it
instead if needed. That is probably overkill in this case.
b. See if &quot;GST_TIME_FORMAT&quot; has a corresponding
&quot;MAX&quot; macro that defines the maximum size of the value that
could get written into a time parameter (something like
GST_TIME_FORMAT_MAX_SIZE), and use that macro in place of 4096.
c. If a. and b. don't pan out, at least write a macro like:
#define GST_TIME_FORMAT_MAX_SIZE 4096
in the .c file and use that instead of 4096, so if by chance we ever need
to increase the size, we only need to increase it in once place (makes the
change less error-prone).