Accessing host from a remote server.

Codec Engine "just runs XDAIS algorithms", so you can structure your codec in any XDAIS-compliant way.  There's no inherent support for 'out of band messaging' in CE as the XDAIS/XDM specs don't define this behavior.

Best case, if your app can wait until the end of the process() call to get this extra info, is to send it from the codec via an extended outArgs from your process() call.  That's a very common pattern many codecs use.

Or if the app needs to know immediately, maybe the codec could "return early" from process() with outArgs that contain the info you want to return to the app, and maybe a flag that the process() call didn't "really" complete and the app should call it again?

Further up the complexity chain, your codec could use some underlying Link-based service (MSGQ?) to send this info to a CE-independent thread in your app (also using MSGQ)?  But at that point you're tying yourself to Link (implying you can't run that codec 'locally') and introducing some ugly dependencies you probably don't want.

Chris

Thanks Chris,

Our requirement (or rather the customer requirement) is that in we do this messaging in the middle of process. So there are two options we have thought of

1) In out current architecture there are 2 XDAIS algorithms AFE and APU, and both execute on DSP, and we do call APU from AFE. Neither AFE nor APU are called via AISA APIs, but we have out own extensions (DEVNODE for AFE and ECO for APU). On the same line we were thinking of having a 3rd XDAIS algorithm (GAIN) that runs locally (on host micro controller) but that can be called from AFE. Now this raises two questions

  a) Using one codec engine is it possible to have some algorithms run locally and some remotely?

  b) If the answer to a is yes, then is it possible to to extend CE APIs (as we have done for AFE and APU) the third time to be able to call the GAIN algorithm

2) The second suggestion is that the process simply interrupts the host and tells it what to do.

Your suggestions are truly appreciated :))

regards

Sachin

sachinpdesai said:

a) Using one codec engine is it possible to have some algorithms run locally and some remotely?

Yep, that's supported.  The same A8-side app can drive local and/or remote algs.

I'm not sure that's what you're suggesting, though.  Reading your suggestion, it sounds like you want a DSP-side 'remote' alg to somehow also act as an _app_ and drive a 'remote-from-the-DSP-POV' alg running on the A8?!  If that's what you mean, that's not supported, and I'd instead suggest you just send a DSP->A8 MSGQ message.

sachinpdesai said:

b) If the answer to a is yes, then is it possible to to extend CE APIs (as we have done for AFE and APU) the third time to be able to call the GAIN algorithm

Yep, extend to your heart's content.  Note that often we recommend using the existing IUNIVERSAL interface rather than create a brand new one like DEVNODE.  While both extension methods are supported, IUNIVERSAL already provides the necessary stubs/skels so there's less work.

sachinpdesai said:

2) The second suggestion is that the process simply interrupts the host and tells it what to do.

Yep, that might be the "just send a DSP->A8 MSGQ message" approach.  Create a separate ARM-side thread that does MSGQ_get() and have the DSP-side do a MSGQ_put() as needed.

Chris

Thanks a lot Chris. Based on your i/p we feel the MSGQ approach suits us best. We want to ensure that the MSGQ implementation is feasible and meets our customers requirements in terms of latency and message size. Is there an example code we can look at? I assume that this implementation is feasible using and interrupts instead of polling on ARM.

Sachin

This is a good starting starting point for a DSP Link-only standalone example:

http://processors.wiki.ti.com/index.php/Audio_Soc_example

It's good in your case as it also uses MSGQ.

There will be some work to use both DSP Link and CE in the same app - e.g. you'll have to #include headers from both CE and Link.  You can probably leverage CE's Engine_open() to load the DSP (but be sure not to use MSGQ before opening the Engine - and similar for Engine_close()).  And depending on how you're building your app, you may want to continue using CE's generated list of libraries (configuro-generated linker.cmd file or package.bld-generated .xdl file) to get the DSP Link libraries on your link line.

Chris

Do I need to do the all or some of the PROC calls shown in that example? I added all the MSGQ calls but I am getting an error when trying to pick up message on ARM (from DSP) DSP_ETIMEOUT.

I'll open with "I'm not a DSP Link expert" and "I haven't done this"... followed by "all the source code is provided, so you may have to dig in a bit yourself".

Assuming you're not calling any DSP Link APIs until after Engine_open(), you're running your MSGQ-using thread from the same process as CE, you're ok using messages from the same POOL as CE (and the msgs in that POOL are the right size and there are enough to spare), you should just have to call MSGQ_open()/get().

Are you passing a timeout value into MSGQ_get()?  Is the DSP side calling MSGQ_locate() and successfully finding the MSGQ that was MSGQ_open()'d on the GPP side?

Chris

how do I ensure "you're ok using messages from the same POOL as CE (and the msgs in that POOL are the right size and there are enough to spare" I am passing a timeout value (5 ms) in MSGQ_get, but I am sure that MSGQ_put is done before so timeout shouldn't matter (I will nevertheless increase timeout and see) I calling MSGQ_locate and it is successfull on DSPS_side.

Thanks Chris. This issue is resolved for now. I am able to get one message asynchronously from the algorithm running on the DSP to the application executing on the host. However I will like to keep this thread alive as I need to do the following improvements

1) Currently I am passing only a message ID, will like to extend this to pass some more data fields.

2) Also I am sending the message upstream only once. Would like to do this a multiple times and from different points in the algorithm to ensure no memory leak etc?

3) The application in currently polling for the message. I would like this to be made interrupt driven, where the interrupt is generated by the algorithm. Can you give me any pointers on how to go about implementing this>

regards

Sachin

I am having some issues with #2 above. I have two places in my algorithm where I put a message in the message queue. The applicationseems to be continously picking up the one I put second. Here is the code flow

Algo()

{

put message A;

put message B;

}

Application()

{

pick up the message and print;

}

the o/p is continuous stream of B. So the issues are

1) Message A is never picked up

2) Message B which has neen put only once seems to be picked up again and again. How do I invalidate a message in the queue?

Your code should look something like this:

ARM:                                               DSP:

    hARM = MSGQ_create("somename")

                                                      hDSP = MSGQ_locate("somename")

    MSGQ_get(hARM)

                                                      MSGQ_alloc(hDSP)

                                                      MSGQ_put(hDSP)

    MSGQ_free(hARM)

    ... some time later

    MSGQ_delete(hARM)

With the green code (ARM-side "get/free" and DSP-side "alloc/put") looping for each msg you send.  Is that what you're doing?

Chris

Thanks once again Chris. The issue is resolved. I was doing

ARM:                                               DSP:

    hARM = MSGQ_create("somename")

                                                      hDSP = MSGQ_locate("somename")

                                                       MSGQ_alloc(hDSP)

                                                       MSGQ_put(hDSP) Put message A

    MSGQ_get(hARM)

                            ... some time later

                                                       MSGQ_put(hDSP) Put message B

    MSGQ_get(hARM)

    ... some more time later

    MSGQ_free(hARM)

    MSGQ_delete(hARM)

With your suggested sequence it works just fine.