Also, I of course meant Dominik Riebeling in my previous commit, sorry.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27700 a1c6a512-1295-4272-9138-f99709370657
this greatly reduces CPU load. lcd_update_rect shoves a bit as well.
CPU usage with Rockbox in background is between 3% (with a 200kbps vbr mp3) and 12% (320kbps cbr mp3), so it's low but still dependent on codecs and even particular files.
Driving a WPS with peakmeter, e.g. the builtin one, adds about 30% cpu usage.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27689 a1c6a512-1295-4272-9138-f99709370657
the activity only attaches to the framebuffer for displaying it. An icon
in the notification area is displayed (it could be prettier I guess).
Note: Some HTC phones won't, includng mine, get enough CPU time to do background decoding
fluently, see: http://code.google.com/p/android/issues/detail?id=9663
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27686 a1c6a512-1295-4272-9138-f99709370657
Android can now be built with CPU_ARM defined
Needs investigation (and test_codec) to see if/how this helps
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27684 a1c6a512-1295-4272-9138-f99709370657
use 'static inline' instead of GCC extension 'inline'
some GCC don't support this (android NDK for example)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27679 a1c6a512-1295-4272-9138-f99709370657
General state is: Rockbox is usable (plays music, saves configuration, touchscreen works too).
Problems:
- Playing music in the background (i.e. when switching to another app) doesn't work reliably, but I'm working on that now.
- no cabbiev2 (only some preliminary files for it), no other default theme.
- screen flickers sometimes if the updates are too frequent
- no multi screen apk/package
- strange behavior when a phone call comes in
The java files (and the eclipse project) resides in android/, which is also supposed to be the build folder.
I've put a small README in there for instructions. There are some steps needed after the make part, which are described there,
and which eclipse mostly handles. But there ought to be some script/makefile rules which do that instead in the future.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27668 a1c6a512-1295-4272-9138-f99709370657
Remove unneeded restriction from set_file that prevented filename settings to
work if they were outside of ROCKBOX_DIR.
Add the get_user_file_path() call to a few further places where it was
forgotten.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27667 a1c6a512-1295-4272-9138-f99709370657
- some variables were defined as const but declared without const
- remove double declaration of mapnames* (already in .h)
- forceOldBsp is boolean, not int
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27660 a1c6a512-1295-4272-9138-f99709370657
For RaaA it evaluates user paths at runtime. For everything but codecs/plugins it will give the path under $HOME/.config/rockbox.org if write access is needed or if the file/folder in question exists there (otherwise it gives /usr/local/share/rockbox).
This allows for installing themes under $HOME as well as having config.cfg and other important files there while installing the application (and default themes) under /usr/local.
On the DAPs it's a no-op, returing /.rockbox directly.
Not converted to use get_user_file_path() are plugins themselves, because RaaA doesn't build plugins yet.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27656 a1c6a512-1295-4272-9138-f99709370657
MAD_FLAG_INCOMPLETE only applies to frame header and isn't an error
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27655 a1c6a512-1295-4272-9138-f99709370657
