Thanks for your information. I like open source tools more, so I would not
consider the Jazelle from a third party. I am wondering if MIDP or CLDC of
J2ME, which is readily downloadable from SUN website, would be a good solution
to provide the Java runtime evironment on DM355. Also, I
Assuming you have access to the codec libraries, you can combine the codecs in
any fashion you want (within resource constraints). The loopback combo (used by
encodedecode demo) has both encoder and decoder included, for example.
Mark
From: [EMAIL PROTECTED]
Ring, Chris wrote:
Given that... users that need this functionality _today_ may have to
resort to hacks in the near term. One system-specific hack/approach
could be to modify CMEM to identify all the alloc requests from the
audio codecs (perhaps by size?), and convert all the requests
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Vladimir Pantelic
Sent: Tuesday, May 27, 2008 10:10 AM
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355
Ring, Chris wrote:
Tivy, Robert wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Vladimir Pantelic
Sent: Tuesday, May 27, 2008 10:10 AM
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355
Ring, Chris
Per the xDAIS spec, codecs themselves never allocate memory, then only
indicate (via the IALG interface) what type of memory they require...
the actual allocation is delegated to the framework (e.g. Codec Engine).
So the codec should never make calls malloc() itself. (One reason not
to 'hack it'
Ring, Chris wrote:
Per the xDAIS spec, codecs themselves never allocate memory, then only
indicate (via the IALG interface) what type of memory they require...
the actual allocation is delegated to the framework (e.g. Codec Engine).
So the codec should never make calls malloc() itself. (One
You can try rand()... lemme know how that works out for you. ;)
We need to get xDAIS updated to understand these other memory spaces -
it's long overdue. We just haven't seen customer demand force the issue
as most xDAIS codecs are running on more embedded OS's (like DSP BIOS)
without virtual
Hi David,
what I am aiming at is not a totally equivalent of OpenCv running with
the full Davinci power - which is far too ambitious from my point of
view (standard OpenCV code will never compile on a DSP). As I wrote in
post and the follow up
Hi David,
Just wondering... did the fix you suggested below permanently fix the audio
write stall problem? For our project, we're now at the point in which we're
fixing issues we put hold on when we first started our code development; one of
these issues is the write (and read) stall problems
Yes, what Lloyd said is what I concerned.
Regards
On Tue, 2008-05-27 at 08:25 -0500, Lloyd Sargent wrote:
On Sunday 25 May 2008 23:41, Kumar, Purushotam wrote:
Albert,
I am not clear about your question.
But official site for MMC is http://www.mmca.org/home and similarly site
for SD
Hi ,
I am working on the davinci .now I encouter a difficult . By reading the
dm6446 datum, I have known that the boot mode of dsp core . I think set DSP_BT
pin to '1' state .using the ccs configure for davinci to emulate it .but I get
the following errrors :
Error connecting to the
Lee, Swami,
I did a simple and quick test. The kernel was also configured with
default setting.
It seems this patch fixed USB stability issue.
test case:
~ 20 files, about 100MBytes every file.
Speed benchmark result on git 2.6.25
-
Read: 3.6M
Hi Andy:
I meet the same problem with you(the write (and read) stall problems), I want
to know how did you recovery it.
After stall happens, I try to reboot system, but it's still stall, until I
reset the power.
Can you show me the code how to fix it, thanks very much.
[EMAIL PROTECTED]
Hi David,
I tried your fix, but still got the write stall problems.
[EMAIL PROTECTED]
2008-05-28
- Original Message -
From: Andy Ngo
To: David A Kondrad,davinci-linux-open-source
Sent: 2008-05-28, 07:28:06
Subject: Re: OSS audio driver under-run breakthrough
Hi David,
Just
Dear Xperts,
I am using the decode() demo on DVEVM DM6446 processor. And for some bit
streams , i noticed that the code used to terminate / didnt decode . Look's
like in the following code below, whenever the progamme goes into the else
condition the programme starts giving problems.
if (status
16 matches
Mail list logo
