[ Looping the mailing list, as this is generally interesting. ] Well... no need to implement your alg's algFree() method, perhaps (though it's recommended).
But your extended API's *_delete() fxn still needs to be implemented. Your extension API implementation - *_create()/delete()/process()/control() - should be independent of OS/processor and built for both sides of the RPC. When the alg is remote, the ARM-side _delete() will be called, and will invoke VISA_delete(). In the VISA_delete() implementation, CE will detect that the alg is remote, and "do what's needed" to invoke your extension API's _delete() on the DSP... which will, exactly as on the ARM, call VISA_delete(). This time, the VISA_delete() implementation will detect that the alg is on the same processor, and will call DSKT2_freeAlg(). This will, as the article describes, _not_ call your alg's algFree(). There is an example in CE's examples/ti/sdo/ce/examples/extensions/scale directory you can model your code after. Chris ________________________________ From: Veeranna [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2008 10:42 PM To: Ring, Chris Subject: Re: Help:: querry on VISA_delete HI Chris, Thanks for the quick response. So no need to impliment delete function in DSP side. Thank you, Veeru ----- Original Message ----- From: Ring, Chris<mailto:[EMAIL PROTECTED]> To: Veeranna<mailto:[EMAIL PROTECTED]> Sent: Tuesday, July 15, 2008 10:17 AM Subject: RE: Help:: querry on VISA_delete Good question, this is a DSKT2 feature. I've added this to the Framework Components FAQ: http://tiexpressdsp.com/wiki/index.php?title=Framework_Components_FAQ#Why_doesn.27t_DSKT2_freeAlg.28.29_call_my_alg.27s_algFree.28.29_method.3F Chris ________________________________ From: Veeranna [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2008 8:53 PM To: Ring, Chris Subject: Help:: querry on VISA_delete Hi All, We are using Codec_eingine_2_10 with my DVEVM 6446 board. we have our extension layer( stub skeleton). Everything is working fine in terms of Create, Process and Control call. Once we call delete from Application ie, it goes to stub and we call VISA_Delete. we see that this delete call never comes to the DSP side. We have mapped this call with the function pointer(Free) in our Function table.In Free function we fill up the memtab structure what codec engine supposed to free.So on the codec side ideally the delete call should be able to print the DSP trace but as per our observation the call never comes to free on dsp side. All the other calls like process, control and create ( it will call 2 function alloc and initobj functions mapped in V table) can be seen on the codec side. Can you please tell whats the reason for the same ? We have seen through the memstats that all the memory is getting Free properly after the Delete call.It seems that VISA_Delete does need the free implementation(In Function Table) on codec side to free the algorithm instance and algorithm heap.. When We was working on xdais compliant code that time we checked the function table, free function gets called from ALG_delete function.So please explain why free function doesnt get called through VISA_delete. Thank you, Veeru -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
