Gstreamer-ti

notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
Ugh, a memory hole, that could easily destabilize the firmware. I'd much prefer if dsplink could be configured to use end or RAM instead, but I understand this can be very difficult thing to do with all that TI stuff.
 

skeezix

Internal Development
Joined
Mar 11, 2003
Messages
8,060
Website
www.codejedi.com
Well, if it works, back to the old 'boot menu' for starting up with key down, so that it could be different boot param files .. like boot1.txt and boot2.txct or something, so could have a memory hole or not? with the hole, could get tight for running apps of course.. or do you think it would get in the way in more nefarious ways?


jeff
 

klaxonn

Still Fresh
Joined
Feb 25, 2011
Messages
88
We played our first video, a xvid with mp3 avi.


For now, just the video part was using DSP, it needs tweaking with the memory.


When we want to only play sound, we have a problem with alsa :

ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: Could not get/set settings from/on resource.


Additional debug info:


gstalsasink.c(520): set_hwparams (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0:


Unable to set hw params for playback: Invalid argument
Any idea ?
 

slaeshjag

¯\_(ツ)_/¯
Joined
Apr 8, 2010
Messages
2,687
Location
~Stockholm, Sweden
That error does kinda ring a bell... Link to the source file where that function fails? Iirc, the ALSA-setup on firmware is very picky about how you set it up, I think there was a simlar issue with QtSpotify.
 
Joined
Oct 9, 2008
Messages
132
We played our first video, a xvid with mp3 avi.


For now, just the video part was using DSP, it needs tweaking with the memory.


When we want to only play sound, we have a problem with alsa :

ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: Could not get/set settings from/on resource.


Additional debug info:


gstalsasink.c(520): set_hwparams (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0:


Unable to set hw params for playback: Invalid argument
Any idea ?
Sorry no idea, but just wondering if you tried using osssink instead.
 

klaxonn

Still Fresh
Joined
Feb 25, 2011
Messages
88
Yes osssink worked. Alsasink too when you overwrite the default plugin.


We have now sound files working with totem : MP3, AAC.
 
Last edited by a moderator:

klaxonn

Still Fresh
Joined
Feb 25, 2011
Messages
88
There is no DSP codec for vorbis.


EDIT : neither for flac. But gstreamer can read these files, just not using the DSP.
 
Last edited by a moderator:

EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,268
Age
42
Location
Ingolstadt
Could you give us the boot parameters for the kernel you used?


Did you have to patch the kernel at all, or did that work out without patching?


We're thinking of including DSP RAM reservation with the next Hotfix, so it would be great to find that out :)
 

klaxonn

Still Fresh
Joined
Feb 25, 2011
Messages
88
For now the boot parameters are :


setenv bootargs ubi.mtd=4 ubi.mtd=3 root=ubi0:rootfs rw omapfb.mode="lcd:800x480-16@65" vram=12M omapfb.vram="1:4M,2:4M,3:4M" omapdss.def_disp=lcd mem=99M@0x80000000 mem=128M@0x88000000


ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr};


But it is used for a boot.txt located in a sd card which boot the nand, as i don't know how to change for a direct boot for nand.


For now, a patch is needed for the kernel to allow a memory hole, as we didn't try to allocate the memory at the end.


I couldn't test much and my priority was to have a DSP working with these initial usual conditions.
 

sepp256

Member
Joined
Sep 4, 2009
Messages
226
setenv bootargs ubi.mtd=4 ubi.mtd=3 root=ubi0:rootfs rw omapfb.mode="lcd:800x480-16@65" vram=12M omapfb.vram="1:4M,2:4M,3:4M" omapdss.def_disp=lcd mem=99M@0x80000000 mem=128M@0x88000000


ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr};
Does this mean that the DSP is using the memory range 0x86300000 ~ 0x87999999? Can I ask why the DSP needs to have a chunk of memory in the middle of main memory rather than at the beginning or the end? Also, are there any implications for the performance of other programs or for memory management? I guess main memory is being fragmented, but there aren't many applications that would need a huge chunk of contiguous memory, right?
 

notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
mem=99M@0x80000000 mem=128M@0x88000000
This looks suspicious - does it really use 29 MB or RAM? The Gumstix article you linked before suggests using "mem=96M@0x80000000 mem=128M@0x88000000" instead.

For now, a patch is needed for the kernel to allow a memory hole, as we didn't try to allocate the memory at the end.
Could you share that patch?


Could you also point me to the recipes you have used? These seem to be newer than in openpandora.org git.

Does this mean that the DSP is using the memory range 0x86300000 ~ 0x87999999? Can I ask why the DSP needs to have a chunk of memory in the middle of main memory rather than at the beginning or the end? Also, are there any implications for the performance of other programs or for memory management? I guess main memory is being fragmented, but there aren't many applications that would need a huge chunk of contiguous memory, right?
AFAIK they just have physical addresses hardcoded in the driver, so we have to clear Linux away from there. Some messed up stuff, I'm also worried that hole thing may cause trouble.
 

klaxonn

Still Fresh
Joined
Feb 25, 2011
Messages
88
This looks suspicious - does it really use 29 MB or RAM? The Gumstix article you linked before suggests using "mem=96M@0x80000000 mem=128M@0x88000000" instead.
I used 99M@0x80000000 because it was generally the examples given on the net. Maybe it's hardcoded somewhere, i can't remember.


Like i said, i wanted to try with the most used parameters before optimize all these values.

Could you share that patch?


Could you also point me to the recipes you have used? These seem to be newer than in openpandora.org git.
I adapted this patch for the 2.6.27 kernel.


I used the recipes from http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-ti.

linux_linux-omap-pm-2.6.27_arch-has-holes.diff.txt
 

Attachments

notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
Thanks for the info, I'll see if this can be integrated in firmware (would prefer tracking down proper authorship of that memhole patch, I think it was Russell King).
 

gunrock

Active Member
Joined
Jan 20, 2011
Messages
511
Ditto.


Get that dsp memory allocated one end of the available ram, and we're looking good!
 

notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
Memory hole patch is now merged to firmware kernel (as it's part of mainline and newer kernels have it anyway). I've tried doing some things with the hole set up on pandora and it seemed to work ok.


dsplink modules and DSP blob will be included too (was surprised newest OE recipes built on our old OE, just with a few hacks). That's ti-dsplink-module, ti-cmem-module, ti-lpm-module, ti-sdma-module, ti-codecs-omap3530-server.


What's left is gstreamer configuration and gstreamer itself (unless there is something else, I've never had it working myself), we won't be adding it to firmware because pandora should not play media by default (patent issues). Hopefully someone can make a guide or maybe cook a pnd.
 
Top