RE: building gstreamer for DM6446

[Vijaydeep Kiran Nadkarni]

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  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
>
> 
>
> 
>
> 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
> /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:
>
> /gstreamer/opensource_build/check-0.9.3>
> CC=arm-none-linux-gnueabi-gcc ./configure --build=i686-linux
> --host=arm-linux --prefix=/gstreamer/filesys/opt/gstreamer
>
> Then calling make I get:
>
> /gstreamer/opensource_build/check-0.9.3> make
> make  all-recursive
> make[1]: Entering directory
> `/gstreamer/opensource_build/check-0.9.3'
> Making all in src
> make[2]: Entering directory
> `/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-g

RE: building gstreamer for DM6446

[Vijaydeep Kiran Nadkarni]

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 /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



 

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
/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:

/gstreamer/opensource_build/check-0.9.3>
CC=arm-none-linux-gnueabi-gcc ./configure --build=i686-linux
--host=arm-linux --prefix=/gstreamer/filesys/opt/gstreamer

Then calling make I get:

/gstreamer/opensource_build/check-0.9.3> make
make  all-recursive
make[1]: Entering directory
`/gstreamer/opensource_build/check-0.9.3'
Making all in src
make[2]: Entering directory
`/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 Gstre

building gstreamer for DM6446

[Vijaydeep Kiran Nadkarni]

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.

Vijay
 
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 package gstreamer_tibuild.tar.gz wasn't on the web site for
download.
Anyone else have a problem building this?
Steve
 

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
 
Jeff, Brian wrote:
Gstreamer for DaVinci TMS320DM6446 is now available for free download,
delivered under LGPL, for the open source community.
 
Several TI business units and engineering teams have been working with
Gstreamer as a foundation for application demos and other project work;
we want to make that port available to the open source community to
enable development and innovation on the DaVinci platform.
 
The completed port for the DaVinci DM6446 DVEVM is available at
http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100 and at
http://linux.davincidsp.com    under the
'downloads' link.
 
This Gstreamer port can be used with TI codecs, 3rd party codecs, or
your own xDM / xDAIS compliant codecs. A companion package of TI digital
media software decoders (licensable object code) is provided along with
the Gstreamer open source release; the companion package includes codec
engine, and some codec servers supporting video and audio decoding.
 
An application note accompanies the download, and describes the build
process and developer entry points. We encourage the use of this
framework for projects on the DaVinci-based devices. The download site
describes the maintainer for this project, Z3 technologies. Z3 will be
hosting the project under GIT version control within the next few weeks.
The website above will contain a quarterly snapshot of the project at it
evolves.
 
The following group of TI developers contributed their efforts to
porting the Gstreamer project to DaVinci for this release:
Rishi Bhattacharya (original port)
Vasant Kumar Easwaran (Complete revamp and bugfixes, port on Davinci)
Pratheesh Gangadhar (Complete revamp and bugfixes + plugins, ports)
Yashwant Vijaykumar (Complete revamp and bugfixes + plugins, ports)
Prateek Bansal and Isara Indra (port to Montavista Linux, addition of
cross-compile functionality, final integration, development of app note)
We would also like to thank the community of developers at
(http://gstreamer.freedesktop.org/) for creating such a powerful and
flexible AV framework; it has b

RE: Davinci-linux-open-source Digest, Vol 27, Issue 23

[Vijaydeep Kiran Nadkarni]

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 seems 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.

 
Vijay 



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 package gstreamer_tibuild.tar.gz wasn't on the web site for
download.

Anyone else have a problem building this?

Steve

 



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

 

Jeff, Brian wrote: 

Gstreamer for DaVinci TMS320DM6446 is now available for free download,
delivered under LGPL, for the open source community.

 

Several TI business units and engineering teams have been working with
Gstreamer as a foundation for application demos and other project work;
we want to make that port available to the open source community to
enable development and innovation on the DaVinci platform. 

 

The completed port for the DaVinci DM6446 DVEVM is available at
http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100 and at
http://linux.davincidsp.com    under the
'downloads' link.

 

This Gstreamer port can be used with TI codecs, 3rd party codecs, or
your own xDM / xDAIS compliant codecs. A companion package of TI digital
media software decoders (licensable object code) is provided along with
the Gstreamer open source release; the companion package includes codec
engine, and some codec servers supporting video and audio decoding. 

 

An application note accompanies the download, and describes the build
process and developer entry points. We encourage the use of this
framework for projects on the DaVinci-based devices. The download site
describes the maintainer for this project, Z3 technologies. Z3 will be
hosting the project under GIT version control within the next few weeks.
The website above will contain a quarterly snapshot of the project at it
evolves. 

 

The following group of TI developers contributed their efforts to
porting the Gstreamer project to DaVinci for this release: 

Rishi Bhattacharya (original port)

Vasant Kumar Easwaran (Complete revamp and bugfixes, port on Davinci)

Pratheesh Gangadhar (Complete revamp and bugfixes + plugins, ports)

Yashwant Vijaykumar (Complete revamp and bugfixes + plugins, ports)

Prateek Bansal and Isara Indra (port to Montavista Linux, addition of
cross-compile functionality, final integration, development of app note)

We would also like to thank the community of developers at
(http://gstreamer.freedesktop.org/) for creating such a powerful and
flexible AV framework; it has been a big benefit for

DM6437 McASP tx issue

[Vijaydeep Kiran Nadkarni]

All,

I have been trying to resolve an issue that I am facing with McASP
transfer and receive drivers on TI's DaVinci TMS320DM6437 DVEVM.

 

My workspace does:

* a real-time video decode in one thread and 

* a simple audio loopback (only receive and transfer using McASP
driver as illustrated by TI's DVSDK for DM6437) in another thread.

 

The audio that I hear at the output is recognizable but noisy (a
crackling noise and what seems to be a distortion of the input). The
noise becomes louder as the volume of the input (audio source)
increases. (The audio source of is clear of any such noise).

 

Other aspects/clues:

* Audio loopback thread is at a higher priority.

* If the McASP transfer  is used to play out audio that is
decoded/stored in memory, not captured (audio data is captured but
discarded), then the audio noise goes away.

* If McBSP is used instead of McASP, the audio noise is still
heard.

---

* If the video decode is turned off the audio noise goes away.

* The video decoder uses only QDMA channels, not any EDMA
channels (that might cause a resource clash with McASP driver)

* Video decoder is interfaced via Codec Engine.

* Video decoder uses DMAN and DSKT2 to acquire all resources and
no hard-coding is done in the decoder with respect to acquiring
resources.

* Code generation and other tools versions:

o   Platform Support Package (PSP) version: 1.00.00.01

o   Codec Engine version: 1.20

o   Code Composer Studio version: 3.3.38.2

o   DSP/BIOS version: 5.31.02

o   Code Generation tools: v6.0.10

 

I do not suspect:

* that the video decoder consumes the entire DSP CPU load or

* that the DDR bandwidth is the constraining factor here.

 

I was wondering if anyone on this mailing list has encountered a similar
issue, i.e. a noise in audio capture or audio playout when a DSP
software module runs in the background. Please, do help out in case you
have a clue as to what may be causing this audio noise.

 

Thanks.

 

Regards,

Vijay

 


**
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