Openal

[Rockthesmurf]

Has anyone compiled OpenAL for Pandora yet? If so were any changes required to the source code? Any configs needing setup?

For PS2 Linux (homebrew development), there was a site called CFYC - Compiled for your Convenience, which hosted many packages that had been prebuilt and were ready to use on PS2 Linux, contributed by the users. It just saved developers having to repeat the same bits of work. Would there be any scope for this on Pandora? Or is it the case most users have a nice way of getting prebuilt packages (some Linux way I am guessing, as I don't know of one for Windows users). The sorts of things I would imagine could be on there would be:

• zlib
• libpng
• openal
• opengles
• devil
• etc

And obviously loads more, I just remember it being quite convenient to be able to just grab the latest/best version of a specific package and be able to use it with no fuss.

Steve

 

[Trickyhero]

We have the App Store(http://apps.open-pandora.org/) and The Archive (http://dl.openhandhelds.org/cgi-bin/pandora.cgi) for distribiting packages. All of the apps just go on your SD cards in the places that you want them in. And just in case if you want to know PS2 will never be possible on the Pandora.

P.S Check the Wiki for a complete list of apps, and also the Archive has more games/apps.

 

[Exophase]

You can get a lot of library binaries off of the Angstrom repository.

 

[Rockthesmurf]

We have the App Store(http://apps.open-pandora.org/) and The Archive (http://dl.openhandhelds.org/cgi-bin/pandora.cgi) for distribiting packages. All of the apps just go on your SD cards in the places that you want them in. And just in case if you want to know PS2 will never be possible on the Pandora.

P.S Check the Wiki for a complete list of apps, and also the Archive has more games/apps.

I don't think you quite got what I was asking about, but thanks for your input anyway...

You can get a lot of library binaries off of the Angstrom repository.

Ah this sounds more interesting, is there a way I can access this from Windows? Is there for instance a web search I can do in the repository, or do I need some mainly Linux program for it? I'm not really clued up on these things, so please forgive my ignorance.

Steve

 

[Exophase]

Ah this sounds more interesting, is there a way I can access this from Windows? Is there for instance a web search I can do in the repository, or do I need some mainly Linux program for it? I'm not really clued up on these things, so please forgive my ignorance.

The method right now (at least, that used by cpasjuste's script) is to get the Angstrom package in ipkg format then use dpkg to extract the contents. Looking around, it seems that 7-zip might support it, so I'd give it a try.

See this topic: http://www.gp32x.de...a-sdk-installer

I think unless you adapt the script for proper paths and use a shell in Windows (like xterm in Cygwin for instance) you'll have to download them manually. Try getting something from here:

http://mydedibox.fr/.../libraries.list

And see if it'll extract. If so you can try doing so at your toolchain root, it should put things in the right places.. but you might want to poke around on that to make sure.

When you have one of those installing you can try getting others from here:

http://www.angstrom-distribution.org/unstable/feed/armv7a/base/

 

[Rockthesmurf]

Very good, I can indeed extract the .so files out of them ipk files, so that's nice, just need to get the correct headers that correspond with the lib version and should be good to go (providing the .so files will correctly link with the Windows CodeSourcery compiler). On the negative side, it does not appear OpenAL is on the libraries.list - how do things get on that list?

Steve

 

[darkblu]

since Exophase did not mention it, here's the web frontend to the Angstrom repo.

 

[Pickle]

the other option is to copy it from the pandora itself, ive done this many times (for the X/gtk libs for example)
I think openal was included int he firmware, at least im sure i requested it since some ports used it.

 

[Rockthesmurf]

Where should they be, in /usr/lib ? I can't find libopenal in either /usr/lib or /lib.

I need to Google for the Linux command to search the entire file system...

Steve

Edit : Found the Linux find command, but couldn't find OpenAL anywhere on NAND.

 

[Pickle]

Where should they be, in /usr/lib ? I can't find libopenal in either /usr/lib or /lib.

I need to Google for the Linux command to search the entire file system...

Steve

Edit : Found the Linux find command, but couldn't find OpenAL anywhere on NAND.

yeah it should have been in the /usr/lib, maybe they didnt there where some i asked that made it and other that didnt.

 

[Rockthesmurf]

After a fair bit of head scratching, I managed to get CMake on Windows to build OpenAL using the CodeSourcery tool chain. I ended up with a little sample application, that dynamically loads my generated .so file and displays information about available OpenAL devices. I still have some stuff to figure out, like why I currently have three .so files:

• libopenal.so
• libopenal.so.1
• libopenal.so.1.12

And what exactly I am meant to do with them, for now I have put them in the same folder as my executable file, and have my LD_LIBRARY_PATH to the directory with the executable file in. Without this, it moaned it couldn't find the .so file.

Also, currently I get two devices, 'OSS Default', and 'Null', the OSS seems to be using Alsa, I'm not sure if that is set up correctly, and if that is what I should expect. There seemed to be some options that might need tweaking during the build process (it's the first time I've used CMake, and actually the first time I've managed to make an executable file that I can run on my Pandora).

Thanks for the help so far, if anyone can shed any light on the little questions above that'd be great.

Steve

 

[lulzfish]

why I currently have three .so files:

• libopenal.so
• libopenal.so.1
• libopenal.so.1.12

This is part of Linux that I know!
Usually, libopenal.so would symlink to libopenal.so.1, which would symlink to libopenal.so.1.12, which is the real one.

This is so that programs can link to libopenal.so and use whatever version happens to be available, even if it's been upgraded later.
It's one of those weird UNIX traditions, I guess. It's sort of practical but I wonder why they don't just have one libopenal.so and leave it at that. Maybe it would screw up the way it's loaded into memory.

So libopenal.so.1.12 is the only one you really need, the rest should be shortcuts to each other.

 

[Rockthesmurf]

Ah, yes get the gist of it, thank you. However, assuming I end up packaging this up as a .pnd file, am I okay to be generating shared .so files? Does the .pnd system provide a directory to put all the .so files which it automatically adds to the LD_LIBRARY_PATH (or something equivalent)?

The next thing I'm going to do is compile a sample app that will just play an audio file through OpenAL, to make sure the devices I have available on my Pandora can actually make some noise!

Steve

Edit: English.

 

[cosam]

However, assuming I end up packaging this up as a .pnd file, am I okay to be generating shared .so files? Does the .pnd system provide a directory to put all the .so files which it automatically adds to the LD_LIBRARY_PATH (or something equivalent)?

It would be a nice feature, wouldn't it? For the time being you can simulate it by setting your PND's executable to a short shell script which sets LD_LIBRARY_PATH and then starts the real executable.

The other Steve

 

[torpor]

Instead of futzing LD_LIBRARY_PATH though, its better to use LD_PRELOAD instead ..

 

[Rockthesmurf]

Instead of futzing LD_LIBRARY_PATH though, its better to use LD_PRELOAD instead ..

Why do you prefer LD_PRELOAD? I know nothing about this, but I did a Google, and on StackOverflow there is this:

What is the LD_PRELOAD trick?

Where someone says:

You can override symbols in the stock libraries by creating a library with the same symbols and specifying the library in LD_PRELOAD.

Some people use it to specify libraries in nonstandard locations, but LD_LIBRARY_PATH is better for that purpose.

Which makes it sound like LD_LIBRARY_PATH is in fact the better method for what I am wanting to do (specify libraries in a nonstandard location).

I am certainly not disagreeing, just trying to understand the reasoning..

Steve

 

[Rockthesmurf]

Hmm, reading up on rpath linker option sounds like it might do what I want, I'll give that a go tonight.

I'm not clear if I need to copy in all three .so files or just one of them. But I'll experiment.

Steve

 

[torpor]

The reason I suggest it is that it is pro-active - with "LD_PRELOAD=/some/path/somelib.so" you are explicitly loading libraries, by path, that your application needs, and you can be fairly sure if you are LD_PRELOAD'ing that you are pulling in the right library before your executable starts .. with LD_LIBRARY_PATH, you're sort of saying "here is the wild thick brush, find the rabbit in there as you will" and .. well .. maybe you'll end up with a hare or a chicken instead of that thar' rabbit ..

 

[Exophase]

Is . included in the standard library search path? If so then you should be OK w/o adding anything, since the pnd is mounted to the cwd.

 

[torpor]

To debug libs during a port, be pro-active and don't assume system sanity. I have gotten into the habit of having an app hierarchy within my $BASE_APP_FOLDER that goes like:

BASE_APP_FOLDER/
   +- Base_App_Executable*
   +- Base_App_Executable_start.sh*
   +- libs/
   +- assets/[sound,images,text,&etc.]

.. and the PND callout goes to $BASE_APP_FOLDER/B*A*Ex*start.sh

In the .sh, you can of course define your own LD_LIBRARY_PATH, but for debugging purposes, I strongly encourage you get LD_PRELOAD chops on the problem, and then just pack the results ..