forcing my IUNIVERSAL codec to be compliant...

Flamingo said:

I'm trying to package my codec in an xdais compliant way. It is derived from IUNIVERSAL. I found the statement "Recall that each XDM algorithm has a create(), control(), process() and delete() function", but when I look for an example of create() in the fir_ti examples, I find no "create" function. There is a UNIVERSAL_create and it calls a VISA_create.

I would have thought that the app would expect to call create with my codec name as the prefix. (As in the "VIDDEC_create".) Would it be more "normal" to wrap UNIVERSAL_create with my codec's name as the prefix?

You have the correct understanding and the doc is a little confusing. Each xDM algorithm is used via create(), control(), process(), delete() in the app, but the algorithm itself will have the functions defined by xdais (i.e. activate(), alloc(), etc), plus control() and process() so it fits the xDM mold.

Flamingo said:

Also, the code for UNIVERSAL_create looks like there is a concern about a race condition,.

Isn't there some kind of critical section wrapper to put around this to prevent the race condition?

Maybe you can elaborate about which part concerns you.

Flamingo said:

Finally (???), I notice that FIR_TI_process has statements of the form "XDM_SETACCESSMODE_READ(inBufs->descs[0].accessMask); I'm not sure what that does or if I need it. Can someone explain how that interacts with the engine?

This is just to tell CE how to manage the cache - you may find Brad's reply here useful: https://community.ti.com/forums/t/4546.aspx 

Thanks. To elaborate on my race condition concern, universal.c says:

<quote>

    /* TODO:M Race here!  Do we need ATM_Increment in our OSAL? */

    if (curInit != TRUE) {

        curInit = TRUE;

        GT_create(&CURTRACE, GTNAME);

    }

<unquote>

It seems obvious that curInit (a static) is set to indicate that create has already been called. Since there is still a "TODO" there, I assume that the race condition would still occur if the task lost control after the if and before the "curInit = TRUE;". I'd be happy to wrap similar code in my _create function with critical code protection. What is the approved mechanism for such protection?

Hi,

First a comment on the universal "create" and "delete".
When it comes to XDM specification these functions are actually defined "logically", and are really implemented at the framework level, not by the actual algorithm.

The framework's "create" function (e.g. VISA_create(), etc.,) actually ends up calling the algorithm's instance creation functions, following the XDAIS/XDM specification, this involves calls to IALG functions (IALG::algAlloc, IALG::algNumalloc, IALG::algInit ) as well as similar IDMA3 and IRES standard functions. Same goes for the "delete".

The "control" and "process" functions are actually, in a way, less standard. They have more defined semantics based on the extended XDM codec class. So, the implementation of a say, framework "process"  function will be implemented as a wrapper around standard  IALG/IRES/IDMA3 interface functions (related to instance activation/deactivation), and codec-class defined call to, say, XDM defined IVIDDEC2::process() function. The latter function call will be universal for algorithm instances of the same codec class (all IVIDDEC2 codecs).

Regarding the race condition discussion above, you are right in the sense that either the framework calls to "create" would need to be protected to ensure serial execution, so that the condition check /block" ... if (curInit==TRUE) " is executed atomically. If the framework cannot guarantee this, the code above will need to implement some critical section around this portion of the code, in order to be reentrant.

Cheers,

Murat

I want to make sure I understand what you are saying. I haven't written the ARM9 app side of the interface yet, so I'm probably making some wrong assumptions. See embedded question marks in comments below.

Let's say my codec is MYALGO and it is derived from IUNIVERSAL. Then the app would do the following:

CERuntime_init();

myCE = Engine_open(...);

myAlgo = IUNIVERSAL_create(...); /* not MYALGO_create ? */

and then a processing loop somewhere:

while (...)

{

    MYALGO_control(myAlgo, ...);

    MYALGO_process(myAlgo, ...);

}

and finally

IUNIVERSAL_delete(myAlgo); /* not MYALGO_delete ? */

Engine_close(myCE);

Ok. If your algo is not one of the VISA Codec Classes, then you can use the IUNIVERSAL APIs.

Have you been looking at:

http://wiki.davincidsp.com/index.php?title=Getting_started_with_IUNIVERSAL

so unless you haven't done so yourself, you should get more familiar as well.
In your example above, you would still need to implement the MYALGO_ APIs as wrappers around IUNIVERSAL_control and IUNIVERSAL_process calls. Check out the FIR example (firtest.c)

Murat

Indeed, mine is not one of the normal VISA types. It will need to be derived from IUNIVERSAL. I have been authoring IUNIVERSAL_control all week (and still have lots to do). The IUNIVERSAL process is actually pretty easy in my case. I have been reading Getting started with IUNIVERSAL. (That was the source of the original quote.)

Nevertheless, it makes more sense to me to create MYALGO_create and MYALGO_delete and just wrap the IUNIVERSAL versions for now. If I later determine that additional things have to occur in create or delete, the app does not have to change, right? Or will the IUIVERSAL versions access my alloc, init, free, etc?

I'm a little confused about the Fxns table too. I found the IALG structure, but I'm not sure where I get an implementationId. My algorithm will not be used on a normal VISA device. In fact it can't be run except on the custom target board we are developing. Is there a list of used implementation IDs somewhere? I think the only numbers I'd need to avoid are those utilized in the Codec Engine and maybe the examples.