Quick note about a nice experience with compile-flags

[lomaxx]

Well,I mostly write this due to my happiness and relief that it now works. So forgive me if I bore you. Maybe someone will find this useful anyway.


I tried to compile sexypsf, a command-line player to play playstation 1 and playstation 2 music-files.


Compiling worked nicely, but when i tried to play some music, I noticed that the sound was stuttering. "top" showed me that the Pandora was pushed to it's limit (99% cpu-usage) and so I though "ah crap, didn't know that sexypsf needs so much cpu-power.


I compared the cpu-usage of sexypsf on my Gentoo-pc - an old Athlon2600+, which isn't THAT much faster than the Pandora and there it only used 5% while playing. And so I thought that there must be something wrong going on.


I searched for some information about compile-flags, stumbled across this thread and without knowing much about what I am doing, I modified the Makefile of sexypsf from

FLAGS = -D__LINUX__ -DPSS_STYLE=1

to

 FLAGS = -DPANDORA -D__LINUX__ -DPSS_STYLE=1 -pipe -march=armv7-a -mcpu=cortex-a8 -mtune=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -fno-inline-functions -O2 -fno-exceptions

The result was quite pleasing. No stuttering and the cpu-usage in "top" ranged from ~35% to 50% for exactly the same song.


Right now I'm happily listening to FinalFantasy9-soundtrack in psf-format (all together ~26MB) playing flawlessly on my Pandora. Well, mabye some other existing player on the Pandora can already do this, but who cares.

 

[mcobit]

Yes, those are set up in the toolchains more or less automatically. On the Pandora itself you have to pass them to the compiler manually


If you used a Toolchain, you can also just use $CFLAGS in your makefile.

 

[lomaxx]

I used the cdevtools-pnd to compile it.


Just noticed that the deadbeef-player supports psf-playback as well. Just that it's stuttering there. :/ Seems to be unoptimized.

 

[sebt3]

Just noticed that the deadbeef-player supports psf-playback as well. Just that it's stuttering there. :/ Seems to be unoptimized.

what about audacious ?

 

[lomaxx]

Plays them but sounds very strange. Either it's a very fast stuttering or some distortion of some kind. Can't really make it out. In any way: It's unusable the way it is. Maybe it's related to some fixing that I read about in the Gentoo-portage-package:

# what about using the correct macro and avoid to cause severe damages to

    # innocent ears?

    sed -i -e "s:AFMT_S16_LE:AFMT_S16_NE:" "${S}"/Linux/oss.c

I'm longing for a decoder-plugin for mpd, but I think that's not easy. the generic-decoder-page of mpd says it would need to read the file from stdin, and output the musicstream to stdout. Maybe there are other ways of implementing it, that i don't know if yet. Well, that's off-topic.


After continuing to port mpd, I will maybe try to compile deadbeaf myself and see if i can get an optimized version of it. It's a nice little player.


Thanks for the feedback. Now i need to go to bed for today. Cya.

 

[Ziz]

Lomaxx: give -O3 a try instead of ANY other optimization. I am quite sure, you will have the same result.


E.g. I think, that -fno-inline-functions is no good choice - my tests showed, that even with very small cache inline functions are much faster ;-)

 

[pisiiki]

Use this:


-O2 -pipe -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp


You can try -O3 but it may cause problems, even "silent" problems. -march doesn't work at all with our cpu I think, I tested it yesterday and it didn't recognize anything.


You can also use qemu-user, it is not the fastest way of building but you can do a nice chroot to the gentoo arm image and build stuff there. It uses all your threads in the pc to build, I think you got like 25% of the pc performance while building and it is easy to setup. Just a couple of sh scripts and you are ready to go with a full system ready to build.


I think I will share my pandora gentoo image soon with easy instructions to chroot. I am testing kde and gnome 3.4 and I want to add transparent wine x86 support too. Suggestions? Someone interested?

 

[lomaxx]

@pisiiki: I'd be interested in such an image. Though i still would like to get Genoo running as booted system on the Pandora. Will try that someday. Getting off-topic again.


I will test the various use-flags when i come home.


How about configure-scripts? When I use the cdevtools-pnd and download a sourcecode-tarball, unpack it, run "./configure" and "make" afterwards, can I expect to get a somewhat optimised binary by that without manualy adding flags?

 

[mcobit]

Use this:


-O2 -pipe -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp


You can try -O3 but it may cause problems, even "silent" problems. -march doesn't work at all with our cpu I think, I tested it yesterday and it didn't recognize anything.


You can also use qemu-user, it is not the fastest way of building but you can do a nice chroot to the gentoo arm image and build stuff there. It uses all your threads in the pc to build, I think you got like 25% of the pc performance while building and it is easy to setup. Just a couple of sh scripts and you are ready to go with a full system ready to build.


I think I will share my pandora gentoo image soon with easy instructions to chroot. I am testing kde and gnome 3.4 and I want to add transparent wine x86 support too. Suggestions? Someone interested?

There was neuvoo, a gentoo fork for Pandora.

How about configure-scripts? When I use the cdevtools-pnd and download a sourcecode-tarball, unpack it, run "./configure" and "make" afterwards, can I expect to get a somewhat optimised binary by that without manualy adding flags?

Type echo $CFLAGS or $CXXFLAGS this is what configurescripts will use for optimization, if not specified otherwise by the buildsystem.


If there is nothing, you can export your compilerflags to these variables to make autotools pick them up.

 

[lomaxx]

uh, oh ... bad. I echoed both variables right after launching the pnd and both seem to be not set to anything as they only output an empty line.


Good to know that. I will try to use your recommended flags in the future.


How about the benefits of the DSP used within SuperZaxxon?


Would I need to recompile stuff with certain flags again to use hardware-support?


Or will it work out of the box for things that it can help with?


Or is it even more complicated and needs modified code? Which would be out of my league.

 

[sebt3]

these flags allow your compiler to use the neon somehow (I've been told badly, but badly is still better than not at all). the DSP is an other league, you'll need to code specifically for it