RE: building gstreamer for DM6446
Thanks for the quick response, Dirk. To call the configure script, I use: CC=arm_v5t_le-gcc ./configure --build=i686-linux --host=arm-linux --prefix=$GSTREAMER_DIR That seems fine to me. GSTREAMER_DIR is defined as my DM6446 file system/opt/gstreamer. This is a valid path and I've installed glib and other libs there. I run make distclean and then I run configure, I get the same output as before. I compile using make clean make install in the check directory This again gives me the same result. I was quite sure the backslashes were causing the problem, so the next time, after running configure I changed the makefiles (simply removed the backslashes) and executed make clean and make install again. This seemed to solve the problem. libcheck.a is now in my file_system/opt/gstreamer/lib/ I still don't know why automake would create an incorrect Makefile. Would anybody know? Vijay From: Dirk Behme [mailto:[EMAIL PROTECTED] Sent: Sun 3/9/2008 2:45 PM To: Vijaydeep Kiran Nadkarni Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: building gstreamer for DM6446 Vijaydeep Kiran Nadkarni wrote: Apologies for the incorrect subject line last time. All, I'm trying to build gstreamer (as provided by TI) for the DM6446. I could not compile check-0.9.3, a lib required by gstreamer. In the log messages during compilation of check, I see the line where a compiler is supposed to run and then the archiver (ar) (to make the lib) runs. The first file the archiver tries archive is check.o. check.c is also the first file that the compiler is supposed to compile. I see something very suspicious where it tries to compile check.c : make[1]: Entering directory `/home/vijay/projects/GStreamer/opensource_build/check-0.9.3/src' source='check.c' object='check.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check.c source='check_error.c' object='check_error.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check_error.c From the logs above, it appears that it doesn't even run the compiler. The back-slashes (\) at the end of the (2nd 3rd) lines makes the group of three lines into one line. I would correct the Makefile, but it isn't provided in the package from TI and is probably created by automake. Any ideas, anyone? Why would automake create an incorrect Makefile? How could I fix this? Appreciate any suggestions. Can you check how configure is called? I don't use MV toolchain, so please replace arm-none-linux-gnueabi-gcc with arm_v5t_le-gcc below. For configure I use use: path_to/gstreamer/opensource_build/check-0.9.3 CC=arm-none-linux-gnueabi-gcc ./configure --build=i686-linux --host=arm-linux --prefix=path_to/gstreamer/filesys/opt/gstreamer Then calling make I get: path_to/gstreamer/opensource_build/check-0.9.3 make make all-recursive make[1]: Entering directory `path_to/gstreamer/opensource_build/check-0.9.3' Making all in src make[2]: Entering directory `path_to/gstreamer/opensource_build/check-0.9.3/src' if arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -MT check.o -MD -MP -MF .deps/check.Tpo -c -o check.o check.c; \ then mv -f .deps/check.Tpo .deps/check.Po; else rm -f .deps/check.Tpo; exit 1; fi ... which results in getting check.o Btw.: I extended make_opensource.sh to have a make distclean in front of each configure. To be on the safe side ;) This results in something like: make distclean CC=arm-none-linux-gnueabi-gcc ./configure ... make What do you get if you go manually to check-0.9.3 directory and execute something like above there? Dirk Brian Jeff wrote: Stephen, The package was built for the latest Montavista kernel on the DM6446 DVEVM. Some additional work may be needed to port this to the latest community open source Linux kernel for DaVinci. Which OS version are you using? Thanks for pointing out the difference in the filename - I'll rename the file back to gstreamer_tibuild.tar.gz to be consistent with the docs. We'll also have a plain text or HTML doc up shortly on the Z3 Technology site. They are getting their CVS / GIT ready. Brian Jeff From: Stephen Berry [EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 8:59 AM To: Jeff, Brian Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: TI is releasing Gstreamer for DaVinci DM6446 to open source This is great - but: Well I just tried it. Of course it didn't compile - the glibc configure failed with: checking for growing stack pointer... configure: error: cannot run test program while cross compiling And the
RE: Error Remote node creation FAILED for multithreaded application combo server
Thanks Mugdha, Can you tell me in what scenarios we get DSP_EFAIL (0x80008008) error? (or suggest some related doc). FYI I am using dsplink_1_30_08_02 and CE 1.02. Regards, Viraj From: Kamoolkar, Mugdha [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 10:30 AM To: Viraj Karandikar; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Error Remote node creation FAILED for multithreaded application combo server Viraj, 0x80008008 is DSPLink error code DSP_EFAIL (refer to $DSPLINK/gpp/inc/errbase.h file). This can occur in multiple scenarios, and not version mismatch only. In fact, in recent versions of DSPLink, version mismatch returns DSP_ECONFIG error, and not DSP_EFAIL. Someone from CE might be able to help with why this failure is occurring. Regards, Mugdha From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viraj Karandikar Sent: Monday, March 10, 2008 10:18 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Error Remote node creation FAILED for multithreaded application combo server Hi, I have a combo server with multiple codecs on DSP side and a multithreaded application on arm side. The application creates a thread for each codec. Each thread opens engine and calls codec APIs. Problem I am facing is, if I try to open 8 threads for codec A first and then 8 threads for codec B, it works fine. But if I reverse the codec order (i.e if I open 8 threads for codec B first and then 8 threads of codec A, then for codec A threads I am getting error as - @0x00084474:[T:0x0002800b] CE - Engine_createNode Remote node creation FAILED (0x80008008). Number of threads out of 8 of codec A which give this error varies for each run. I have checked and I am getting non-NULL CE handle with no error code. Also somewhere on net I read that above error code 0x80008008 indicates dsp link layer version mismatch. But then this error should have come in all cases for all threads. I also tried ensuring that a thread's call to Engine_open() is complete before other thread calls its Engine_open. (by using mutex) . But it didn't resolve the problem. If I create any number of threads only for codec A or only for codec B, then application works fine with no errors. Any help is welcome J Regards, Viraj ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] ** ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM355 Audio Video Mux
It's not impossible to do it yourself, have a look for the OpenDML 2.0 specification online. MSDN is useful for structure defs and explanations etc. Then you have full control over index structure, insertion of extra data, etc. However be prepared for plenty of head scratching and gathering bits of different specs together for the audio and MPEG video parts.. This is what I've done / tried to do, and it's not quite right yet, but playable :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Diego Dompe Sent: 07 March 2008 17:16 To: [EMAIL PROTECTED] Cc: Linux DaVinci Subject: Re: DM355 Audio Video Mux Hi, You can do this with gstreamer. RidgeRun offers gstreamer and audio/video codecs solutions for DM355 integrated with TI Codecs, if you are interested. Diego Dompe RidgeRun Engineering On Mar 7, 2008, at 11:07 AM, [EMAIL PROTECTED] wrote: I am investigating the possibility of using the DM355 in some of our products. But we have a requirement that files generated by our product should be able to be run on any computer without installing additional software. This in my mind means we have to create an AVI program stream. Our video clips would range between 10 seconds and 1 minute with ~5mins between clips so the files might easily be post processed on the DM355. But It would be nice if the files could be written as the AVI stream directly. Has anyone figured out how to do this yet and could point me in the correct direction. Tim -- Tim Taylor Electrical Engineer L-3 Communications [EMAIL PROTECTED] BLOCKED::mailto:[EMAIL PROTECTED] ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Racelogic is a limited company registered in England. Registered number 2743719. Registered Office 5 Little Balmer, Buckingham Ind Pk, Buckingham MK18 1TF. The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Error Remote node creation FAILED for multithreaded application combo server
Vijay,
To find out exactly where the failure occurred, you can try the
following technique of enabling SET_FAILURE_REASON prints:
Enable SET_FAILURE_REASON print:
File: /${DSPLINK}/dsplink/gpp/src/gen/trc.c
Function: TRC_SetReason ()
Existing Code:
#if defined(DDSP_DEBUG)
TRC_3PRINT (TRC_LEVEL7,
Failure [0x%x] in [0x%x] at line %d\n,
status, FileId, Line) ;
#endif /* #if defined(DDSP_DEBUG) */
Add:
PRINT_Printf (Failure [0x%x] in [0x%x] at line %d\n,
status, FileId, Line) ;
* Now rebuild the GPP-side of DSPLink.
* Run the application
* Some kernel prints will be seen of the type:
Failure [0x8000800C] in [0x71B] at line 455
To interpret this:
*
* The numbers in the above statement (0x8000800C, 0x71B
and line 455) refer to sources of release v1.40.05.
* File /${DSPLINK}/gpp/inc/_signature.h has the
identifiers for all source files.
* 0x8000800C is the error code. It is DSP_EMEMORY (refer
to section above for this interpretation).
* The 0x71B refers to file identifiers. From the
_signature.h file, this corresponds to FID_C_LDRV_POOL source file, i.e.
ldrv_pool.c.
* The line number is 455 within the ldrv_pool.c file. This
indicates that the failure DSP_EMEMORY is due to failure in the
allocation from shared memory, which means that the amount of shared
memory specified for the pool cannot fit into the specified memory entry
in the configuration.
The first SET_FAILURE_REASON print usually indicates the original cause
of failure. The subsequent failures usually occur as a result of the
first failure.
Regards,
Mugdha
From: Viraj Karandikar [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2008 2:17 PM
To: Kamoolkar, Mugdha; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Error Remote node creation FAILED for multithreaded
application combo server
Thanks Mugdha,
Can you tell me in what scenarios we get DSP_EFAIL (0x80008008) error?
(or suggest some related doc).
FYI I am using dsplink_1_30_08_02 and CE 1.02.
Regards,
Viraj
From: Kamoolkar, Mugdha [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2008 10:30 AM
To: Viraj Karandikar; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Error Remote node creation FAILED for multithreaded
application combo server
Viraj,
0x80008008 is DSPLink error code DSP_EFAIL (refer to
$DSPLINK/gpp/inc/errbase.h file). This can occur in multiple scenarios,
and not version mismatch only. In fact, in recent versions of DSPLink,
version mismatch returns DSP_ECONFIG error, and not DSP_EFAIL.
Someone from CE might be able to help with why this failure is
occurring.
Regards,
Mugdha
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Viraj Karandikar
Sent: Monday, March 10, 2008 10:18 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Error Remote node creation FAILED for multithreaded
application combo server
Hi,
I have a combo server with multiple codecs on DSP side and a
multithreaded application on arm side. The application creates a thread
for each codec.
Each thread opens engine and calls codec APIs. Problem I am facing is,
if I try to open 8 threads for codec A first and then 8 threads for
codec B, it works fine.
But if I reverse the codec order (i.e if I open 8 threads for codec B
first and then 8 threads of codec A, then for codec A threads I am
getting error as -
@0x00084474:[T:0x0002800b] CE - Engine_createNode Remote node creation
FAILED (0x80008008).
Number of threads out of 8 of codec A which give this error varies for
each run.
I have checked and I am getting non-NULL CE handle with no error code.
Also somewhere on net I read that above error code 0x80008008 indicates
dsp link layer version mismatch.
But then this error should have come in all cases for all threads.
I also tried ensuring that a thread's call to Engine_open() is complete
before other thread calls its Engine_open. (by using mutex) . But it
didn't resolve the problem.
If I create any number of threads only for codec A or only for codec B,
then application works fine with no errors.
Any help is welcome J
Regards,
Viraj
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
[EMAIL PROTECTED]
**
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DSP Link 1.40.05 Test suite failure
Hi, We are trying to execute the test cases under test suites in dsplink 1.40.05. We could execute the API tests (for CHNL, PROC and MSGQ components) successfully, but we are getting the following error while executing Basic Functionality Tests of CHNL component. Suite : LinkChnlBvrTest Test : BVR_ReclaimTimeout DSP_SOK DSP_SOK DSP_ETIMEOUT DSP_SOK 0 /opt/dsplink/test/dsp/bin/reclaimtimeout.out 0 200 400 500 16384 ERROR : First Reclaim ended with unexpected status. Status = [0x8000] INFO : Status: Expected [0x8000] INFO : Status: Got [0x80008008] Status : Failed 0x80008008 We are getting this failure for all reclaim timeout tests. Can we get the root cause for the above issue? Thanks, SARA ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Frame buffer driver for TMS320DM6437
Hi Has anybody developed TMS320DM6437 frame buffer driver (Linux) by any chance ? Please share with me if anybody has this info. Regards Vidya. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
porting gnash on DM355
Hi, I need to port Flash-player on the DM355 board. I found that Gnash has been ported on ARM. Can somebody provide links for instructions on how to port gnash on the DM355 board? I have tried, but unable figure out the cross compile options for configure. Need some advice on this. Is it ok to boot DM355 through nfs and put the gnash in the filesys/opt on the host and compile the same on target? Thanks. Warm Regards, Phaneendra Varma S.V.R Senior Software Engineer Email: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Board : +91 - 4009 P Please consider the environment before printing this email Visit us at www.tanlasolutions.comhttp://www.tanlasolutions.com Download Tanla Mobile - Marketing and Advertising Guide. http://www.tanlamobile.com/guide/ Colombo | Dubai | Dublin | Hyderabad | London | Mumbai | New Delhi | New York | Singapore DISCLAIMER: This e-mail is intended only for the addressee. If you are not the intended recipient, then dissemination, distribution or copying of this email is strictly prohibited. If received in error, please destroy the e-mail and notify the sender immediately. This mail has been checked for viruses. However recipients should undertake their own virus check. Tanla Solutions Limited and its subsidiaries will not be liable for any losses. Download Tanla Mobile Marketing and Advertising Guide. http://www.tanlamobile.com/main.html * This e-mail is intended only for the addressee. If you are not the intended recipient, then dissemination, distribution or copying of this email is strictly prohibited. If received in error, please destroy the e-mail and notify the sender immediately. This mail has been checked for viruses. However recipients should undertake their own virus check. Tanla Solutions Limited and its subsidiaries will not be liable for any losses. ** ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: OSD + V4L2 query
Yes. Murali Karicheri From: Faro Maza, Virginia [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2008 2:58 AM To: Karicheri, Muralidharan; davinci-linux-open-source@linux.davincidsp.com Cc: [EMAIL PROTECTED] Subject: RE: OSD + V4L2 query Thank you very much for your comments. Does the same apply for the DM6446? Virginia -Original Message- From: Karicheri, Muralidharan [mailto:[EMAIL PROTECTED] Sent: Fri 3/7/2008 4:53 PM To: [EMAIL PROTECTED]; Faro Maza, Virginia Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: OSD + V4L2 query I agree. DM355 VPFE doesn't have capability to blend text with video before capturing. It can only blend text/graphics with video using the OSD in the VPBE. Murali From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 07, 2008 11:46 AM To: [EMAIL PROTECTED] Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: OSD + V4L2 query That is not possible (unless someone want to correct me). Your options are: - Put the text in the OSD buffer (/dev/fb/0) and it will be blended before output from VPBE - Draw the text onto the buffer in memory, using software - Add hardware to overlay the text before it goes into the VPFE. Just to note, the hardware (355 anyway) does not support blending OSD graphics before encoding video, if that is what you are trying to do. We have ended up using an external encoder chip to do this. From: [EMAIL PROTECTED] idsp.com [mailto:[EMAIL PROTECTED] x.davincidsp.com] On Behalf Of Faro Maza, Virginia Sent: 07 March 2008 15:43 To: davinci-linux-open-source@linux.davincidsp.com Subject: OSD + V4L2 query Hi all, I have been using the TI encode demo, where the video processing back end is used to display raw video frames (captured with the V4L2 driver) as well as an OSD layer of text in an LCD monitor. In the encode demo, each video frame is captured from /dev/video0 and then copied (using the hardware resizer) into /dev/fb/3. Simultaneously, dynamic data (e.g. CPU load) is written into the OSD window /dev/fb/0. The transparency is set through /dev/fb/2, which is opened as an attribute window. I would like to blend an OSD layer of text with my raw video before it is captured by the V4L2 driver. How can I do that? Many thanks, Virginia Faro-Maza American Dynamics Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Tyco Safety Products/CEM Systems Ltd. Registered in Northern Ireland: NI 25728. Registered Office: Unit 4 Ravenhill Business Park, Ravenhill Road, Belfast, BT6 8AW.. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete any copies in your possession. Racelogic is a limited company registered in England. Registered number 2743719. Registered Office 5 Little Balmer, Buckingham Ind Pk, Buckingham MK18 1TF. The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Frame buffer driver for TMS320DM6437
Hi Satya I did not understand your question. Can you just elaborate on this ? Regards Vidya. -Original Message- From: Venkatachari, Sathyanarayan [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 6:53 PM To: Vidyadhara Talya (WT01 - Embedded Product Engineering) Subject: RE: Frame buffer driver for TMS320DM6437 Is dm6437 not a dsp only part ?? Regards, sathya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] p.com] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 10, 2008 5:12 PM To: [EMAIL PROTECTED]; davinci-linux-open-source@linux.davincidsp.com Subject: Frame buffer driver for TMS320DM6437 Hi Has anybody developed TMS320DM6437 frame buffer driver (Linux) by any chance ? Please share with me if anybody has this info. Regards Vidya. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Need some information for writing Capture and display videoapplication
Are you using DM355 or DM6446 ? I am assuming you are using TI driver for doing the resize. Murali From: [EMAIL PROTECTED] om [mailto:[EMAIL PROTECTED] ncidsp.com] On Behalf Of Amol S Sent: Saturday, March 08, 2008 6:00 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Need some information for writing Capture and display videoapplication Hello. I am trying to write small application to capture and display video. I have capture device as CMOS sensor that is giving me 10 bit RAW RGB data. I am using preview that converts the captured data in YUV format and then passing the preview buffer to resizer as input buffer. But on screen I am getting garbage data. But when I tried to dump the preview buffer directly to display buffer (without use of resizer) it is displaying proper captured data. Can I get some pointers or information that will help to write such application? Thanks in advance. Thanks, Amol ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Frame buffer driver for TMS320DM6437
Vidya, DM6437 is DSP only device. We provide and support DSP-BIOS based driver for DM6437 device. You can download the DM6437 software from www.ti.com/dvevmupdates Have you ported Linux on this device? FYI, One of our third party (virtual logix) offers Linux package for DM6437. See the link below http://www.virtuallogix.com/index.php?id=62tx_ttnews%5Btt_news%5D=124t x_ttnews%5BbackPid%5D=85cHash=d0b9f27dc5 Best Regards, Brijesh Singh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 10, 2008 8:36 AM To: Venkatachari, Sathyanarayan Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: Frame buffer driver for TMS320DM6437 Hi Satya I did not understand your question. Can you just elaborate on this ? Regards Vidya. -Original Message- From: Venkatachari, Sathyanarayan [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 6:53 PM To: Vidyadhara Talya (WT01 - Embedded Product Engineering) Subject: RE: Frame buffer driver for TMS320DM6437 Is dm6437 not a dsp only part ?? Regards, sathya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] p.com] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 10, 2008 5:12 PM To: [EMAIL PROTECTED]; davinci-linux-open-source@linux.davincidsp.com Subject: Frame buffer driver for TMS320DM6437 Hi Has anybody developed TMS320DM6437 frame buffer driver (Linux) by any chance ? Please share with me if anybody has this info. Regards Vidya. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Frame buffer driver for TMS320DM6437
Hi Brijesh We are actually doing a migration project from having a VGA card ( for supporting graphics) to DM6437. So actually in the new system, there is no VGA involved. The existing system uses DirectFb in order to support the graphics part. This aspect needs to be retained when shifting to DSP 6437. When I searched for a frame buffer driver for DM6437, I hit upon DSP 6446 frame buffer driver at the directFB site. So my question is, has anybody as such, developed a 6437 frame buffer driver ? The difference, I see here is that 6446 is controlled by ARM controller, where as 6437 does not have this instead it has the PCI bus support. Regards Vidya. -Original Message- From: Singh, Brijesh [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 8:36 PM To: Vidyadhara Talya (WT01 - Embedded Product Engineering); Venkatachari, Sathyanarayan Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: Frame buffer driver for TMS320DM6437 Vidya, DM6437 is DSP only device. We provide and support DSP-BIOS based driver for DM6437 device. You can download the DM6437 software from www.ti.com/dvevmupdates Have you ported Linux on this device? FYI, One of our third party (virtual logix) offers Linux package for DM6437. See the link below http://www.virtuallogix.com/index.php?id=62tx_ttnews%5Btt_news%5D=124t x_ttnews%5BbackPid%5D=85cHash=d0b9f27dc5 Best Regards, Brijesh Singh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 10, 2008 8:36 AM To: Venkatachari, Sathyanarayan Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: Frame buffer driver for TMS320DM6437 Hi Satya I did not understand your question. Can you just elaborate on this ? Regards Vidya. -Original Message- From: Venkatachari, Sathyanarayan [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 6:53 PM To: Vidyadhara Talya (WT01 - Embedded Product Engineering) Subject: RE: Frame buffer driver for TMS320DM6437 Is dm6437 not a dsp only part ?? Regards, sathya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] p.com] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 10, 2008 5:12 PM To: [EMAIL PROTECTED]; davinci-linux-open-source@linux.davincidsp.com Subject: Frame buffer driver for TMS320DM6437 Hi Has anybody developed TMS320DM6437 frame buffer driver (Linux) by any chance ? Please share with me if anybody has this info. Regards Vidya. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Davinci-linux-open-source mailing list
RE: Error Remote node creation FAILED for multithreaded application combo server
I don't suspect this to be a Link error as a fork on this thread is chasing. More likely, it's a mis-configured server.cfg script. As a simple example, consider the following: * codec A and codec B share internal scratch memory * codec A needs 40k, codec B needs 50k * codec A and B are placed into scratch group 0 * there is 64k configured for internal memory The server.cfg script _should_ configure 50k (the max for all codecs) into scratch group 0. However, if the server.cfg script only configured 40k... * If codec A is created first, 40k (max of configured mem - 40k - and requested mem - 40k) will be allocated. When codec B is created, there's not enough memory in scratch (only 40k was allocated), so the creation of alg B may fail. * If codec B is created first, 50k (max of configured mem - 40k - and requested mem - 50k) will be allocated. Creating codec A later will succeed. [ That's a simple example, but the same concept applies to DMA and other resources as well. ] These can get a bit tricky - I might suggest you open a ticket with TI's software support so they can help dig in a bit more. Unfortunately, CE 1.02 had little tracing support for getting further insight into these complex codec resources requests. CE 2.00 and later have much better tracing support for these things, if you have the flexibility to upgrade. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viraj Karandikar Sent: Sunday, March 09, 2008 9:48 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Error Remote node creation FAILED for multithreaded application combo server Hi, I have a combo server with multiple codecs on DSP side and a multithreaded application on arm side. The application creates a thread for each codec. Each thread opens engine and calls codec APIs. Problem I am facing is, if I try to open 8 threads for codec A first and then 8 threads for codec B, it works fine. But if I reverse the codec order (i.e if I open 8 threads for codec B first and then 8 threads of codec A, then for codec A threads I am getting error as - @0x00084474:[T:0x0002800b] CE - Engine_createNode Remote node creation FAILED (0x80008008). Number of threads out of 8 of codec A which give this error varies for each run. I have checked and I am getting non-NULL CE handle with no error code. Also somewhere on net I read that above error code 0x80008008 indicates dsp link layer version mismatch. But then this error should have come in all cases for all threads. I also tried ensuring that a thread's call to Engine_open() is complete before other thread calls its Engine_open. (by using mutex) . But it didn't resolve the problem. If I create any number of threads only for codec A or only for codec B, then application works fine with no errors. Any help is welcome J Regards, Viraj ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] ** ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: building gstreamer for DM6446
Do you use Cygwin and Windows? Dirk Vijaydeep Kiran Nadkarni wrote: Thanks for the quick response, Dirk. To call the configure script, I use: CC=arm_v5t_le-gcc ./configure --build=i686-linux --host=arm-linux --prefix=$GSTREAMER_DIR That seems fine to me. GSTREAMER_DIR is defined as my DM6446 file system/opt/gstreamer. This is a valid path and I've installed glib and other libs there. I run make distclean and then I run configure, I get the same output as before. I compile using make clean make install in the check directory This again gives me the same result. I was quite sure the backslashes were causing the problem, so the next time, after running configure I changed the makefiles (simply removed the backslashes) and executed make clean and make install again. This seemed to solve the problem. libcheck.a is now in my file_system/opt/gstreamer/lib/ I still don’t know why automake would create an incorrect Makefile. Would anybody know? Vijay *From:* Dirk Behme [mailto:[EMAIL PROTECTED] *Sent:* Sun 3/9/2008 2:45 PM *To:* Vijaydeep Kiran Nadkarni *Cc:* davinci-linux-open-source@linux.davincidsp.com *Subject:* Re: building gstreamer for DM6446 Vijaydeep Kiran Nadkarni wrote: Apologies for the incorrect subject line last time. All, I'm trying to build gstreamer (as provided by TI) for the DM6446. I could not compile check-0.9.3, a lib required by gstreamer. In the log messages during compilation of check, I see the line where a compiler is supposed to run and then the archiver (ar) (to make the lib) runs. The first file the archiver tries archive is check.o. check.c is also the first file that the compiler is supposed to compile. I see something very suspicious where it tries to compile check.c : make[1]: Entering directory `/home/vijay/projects/GStreamer/opensource_build/check-0.9.3/src' source='check.c' object='check.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check.c source='check_error.c' object='check_error.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check_error.c From the logs above, it appears that it doesn't even run the compiler. The back-slashes (\) at the end of the (2nd 3rd) lines makes the group of three lines into one line. I would correct the Makefile, but it isn't provided in the package from TI and is probably created by automake. Any ideas, anyone? Why would automake create an incorrect Makefile? How could I fix this? Appreciate any suggestions. Can you check how configure is called? I don't use MV toolchain, so please replace arm-none-linux-gnueabi-gcc with arm_v5t_le-gcc below. For configure I use use: path_to/gstreamer/opensource_build/check-0.9.3 CC=arm-none-linux-gnueabi-gcc ./configure --build=i686-linux --host=arm-linux --prefix=path_to/gstreamer/filesys/opt/gstreamer Then calling make I get: path_to/gstreamer/opensource_build/check-0.9.3 make make all-recursive make[1]: Entering directory `path_to/gstreamer/opensource_build/check-0.9.3' Making all in src make[2]: Entering directory `path_to/gstreamer/opensource_build/check-0.9.3/src' if arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -MT check.o -MD -MP -MF .deps/check.Tpo -c -o check.o check.c; \ then mv -f .deps/check.Tpo .deps/check.Po; else rm -f .deps/check.Tpo; exit 1; fi ... which results in getting check.o Btw.: I extended make_opensource.sh to have a make distclean in front of each configure. To be on the safe side ;) This results in something like: make distclean CC=arm-none-linux-gnueabi-gcc ./configure ... make What do you get if you go manually to check-0.9.3 directory and execute something like above there? Dirk Brian Jeff wrote: Stephen, The package was built for the latest Montavista kernel on the DM6446 DVEVM. Some additional work may be needed to port this to the latest community open source Linux kernel for DaVinci. Which OS version are you using? Thanks for pointing out the difference in the filename - I'll rename the file back to gstreamer_tibuild.tar.gz to be consistent with the docs. We'll also have a plain text or HTML doc up shortly on the Z3 Technology site. They are getting their CVS / GIT ready. Brian Jeff From: Stephen Berry [EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 8:59 AM To: Jeff, Brian Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: TI is releasing Gstreamer for DaVinci DM6446 to open source This is great - but: Well I just tried it. Of course it didn't compile
About SD controller of DaVinci
Hi all, I'm currently tracing the SDIO stack patch for DaVinci MV kernel, released by TI. I found that there are register definitions which aren't described in the document (SPRUE30B). They are: SDIOCTL: 0x64 SDIOST0: 0x68 SDIOIEN: 0x6C SDIOIST: 0x70 It means DaVinci doesn't support SDIO? Does anyone know about the detail? Ramax ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Need some information for writing Capture and display video application
Yes I am using TI DaVinci DM6446 and using TI driver for resize. Thanks, Amol M Shrotri _ From: Karicheri, Muralidharan [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 7:20 PM To: Amol S; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Need some information for writing Capture and display videoapplication Are you using DM355 or DM6446 ? I am assuming you are using TI driver for doing the resize. Murali _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] sp.com] On Behalf Of Amol S Sent: Saturday, March 08, 2008 6:00 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Need some information for writing Capture and display videoapplication Hello. I am trying to write small application to capture and display video. I have capture device as CMOS sensor that is giving me 10 bit RAW RGB data. I am using preview that converts the captured data in YUV format and then passing the preview buffer to resizer as input buffer. But on screen I am getting garbage data. But when I tried to dump the preview buffer directly to display buffer (without use of resizer) it is displaying proper captured data. Can I get some pointers or information that will help to write such application? Thanks in advance. Thanks, Amol - This message has been scanned for viruses, spam and dangerous content and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: building gstreamer for DM6446
Nope. I use a linux machine. Vijay From: Dirk Behme [mailto:[EMAIL PROTECTED] Sent: Tue 3/11/2008 1:14 AM To: Vijaydeep Kiran Nadkarni Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: building gstreamer for DM6446 Do you use Cygwin and Windows? Dirk Vijaydeep Kiran Nadkarni wrote: Thanks for the quick response, Dirk. To call the configure script, I use: CC=arm_v5t_le-gcc ./configure --build=i686-linux --host=arm-linux --prefix=$GSTREAMER_DIR That seems fine to me. GSTREAMER_DIR is defined as my DM6446 file system/opt/gstreamer. This is a valid path and I've installed glib and other libs there. I run make distclean and then I run configure, I get the same output as before. I compile using make clean make install in the check directory This again gives me the same result. I was quite sure the backslashes were causing the problem, so the next time, after running configure I changed the makefiles (simply removed the backslashes) and executed make clean and make install again. This seemed to solve the problem. libcheck.a is now in my file_system/opt/gstreamer/lib/ I still don't know why automake would create an incorrect Makefile. Would anybody know? Vijay *From:* Dirk Behme [mailto:[EMAIL PROTECTED] *Sent:* Sun 3/9/2008 2:45 PM *To:* Vijaydeep Kiran Nadkarni *Cc:* davinci-linux-open-source@linux.davincidsp.com *Subject:* Re: building gstreamer for DM6446 Vijaydeep Kiran Nadkarni wrote: Apologies for the incorrect subject line last time. All, I'm trying to build gstreamer (as provided by TI) for the DM6446. I could not compile check-0.9.3, a lib required by gstreamer. In the log messages during compilation of check, I see the line where a compiler is supposed to run and then the archiver (ar) (to make the lib) runs. The first file the archiver tries archive is check.o. check.c is also the first file that the compiler is supposed to compile. I see something very suspicious where it tries to compile check.c : make[1]: Entering directory `/home/vijay/projects/GStreamer/opensource_build/check-0.9.3/src' source='check.c' object='check.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check.c source='check_error.c' object='check_error.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check_error.c From the logs above, it appears that it doesn't even run the compiler. The back-slashes (\) at the end of the (2nd 3rd) lines makes the group of three lines into one line. I would correct the Makefile, but it isn't provided in the package from TI and is probably created by automake. Any ideas, anyone? Why would automake create an incorrect Makefile? How could I fix this? Appreciate any suggestions. Can you check how configure is called? I don't use MV toolchain, so please replace arm-none-linux-gnueabi-gcc with arm_v5t_le-gcc below. For configure I use use: path_to/gstreamer/opensource_build/check-0.9.3 CC=arm-none-linux-gnueabi-gcc ./configure --build=i686-linux --host=arm-linux --prefix=path_to/gstreamer/filesys/opt/gstreamer Then calling make I get: path_to/gstreamer/opensource_build/check-0.9.3 make make all-recursive make[1]: Entering directory `path_to/gstreamer/opensource_build/check-0.9.3' Making all in src make[2]: Entering directory `path_to/gstreamer/opensource_build/check-0.9.3/src' if arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -MT check.o -MD -MP -MF .deps/check.Tpo -c -o check.o check.c; \ then mv -f .deps/check.Tpo .deps/check.Po; else rm -f .deps/check.Tpo; exit 1; fi ... which results in getting check.o Btw.: I extended make_opensource.sh to have a make distclean in front of each configure. To be on the safe side ;) This results in something like: make distclean CC=arm-none-linux-gnueabi-gcc ./configure ... make What do you get if you go manually to check-0.9.3 directory and execute something like above there? Dirk Brian Jeff wrote: Stephen, The package was built for the latest Montavista kernel on the DM6446 DVEVM. Some additional work may be needed to port this to the latest community open source Linux kernel for DaVinci. Which OS version are you using? Thanks for pointing out the difference in the filename - I'll rename the file back to gstreamer_tibuild.tar.gz to be consistent with the docs. We'll also have a plain text or HTML doc up shortly on the Z3 Technology site. They are getting their CVS / GIT ready. Brian Jeff
RE: Error Remote node creation FAILED for multithreaded application combo server
Thanks Chris, Your guess was correct. DSKT2.ALLOW_EXTERNAL_SCRATCH parameter in server.cfg file was set to false. Changing it to true, solved the problem J Thanks again J Viraj From: Ring, Chris [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 11:16 PM To: Viraj Karandikar; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Error Remote node creation FAILED for multithreaded application combo server I don't suspect this to be a Link error as a fork on this thread is chasing. More likely, it's a mis-configured server.cfg script. As a simple example, consider the following: * codec A and codec B share internal scratch memory * codec A needs 40k, codec B needs 50k * codec A and B are placed into scratch group 0 * there is 64k configured for internal memory The server.cfg script _should_ configure 50k (the max for all codecs) into scratch group 0. However, if the server.cfg script only configured 40k... * If codec A is created first, 40k (max of configured mem - 40k - and requested mem - 40k) will be allocated. When codec B is created, there's not enough memory in scratch (only 40k was allocated), so the creation of alg B may fail. * If codec B is created first, 50k (max of configured mem - 40k - and requested mem - 50k) will be allocated. Creating codec A later will succeed. [ That's a simple example, but the same concept applies to DMA and other resources as well. ] These can get a bit tricky - I might suggest you open a ticket with TI's software support so they can help dig in a bit more. Unfortunately, CE 1.02 had little tracing support for getting further insight into these complex codec resources requests. CE 2.00 and later have much better tracing support for these things, if you have the flexibility to upgrade. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viraj Karandikar Sent: Sunday, March 09, 2008 9:48 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Error Remote node creation FAILED for multithreaded application combo server Hi, I have a combo server with multiple codecs on DSP side and a multithreaded application on arm side. The application creates a thread for each codec. Each thread opens engine and calls codec APIs. Problem I am facing is, if I try to open 8 threads for codec A first and then 8 threads for codec B, it works fine. But if I reverse the codec order (i.e if I open 8 threads for codec B first and then 8 threads of codec A, then for codec A threads I am getting error as - @0x00084474:[T:0x0002800b] CE - Engine_createNode Remote node creation FAILED (0x80008008). Number of threads out of 8 of codec A which give this error varies for each run. I have checked and I am getting non-NULL CE handle with no error code. Also somewhere on net I read that above error code 0x80008008 indicates dsp link layer version mismatch. But then this error should have come in all cases for all threads. I also tried ensuring that a thread's call to Engine_open() is complete before other thread calls its Engine_open. (by using mutex) . But it didn't resolve the problem. If I create any number of threads only for codec A or only for codec B, then application works fine with no errors. Any help is welcome J Regards, Viraj ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] ** ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
