How many people still use old Archos devices?

[dreamlayers]

How many people still use old Archos devices? If you're using one, which Rockbox version do you use?

I still have my Archos V2 Recorder. (That's like the FM Recorder but without the FM radio receiver hardware.) Since it's large and heavy, I don't carry it around much. I only use it if I want to listen to something in bed. I think it's more rugged and less prone to damage if I fall asleep with it still on my bed.

In 2007, I stopped updating the Rockbox version I use on there. There's only 2 MB of RAM, and I wanted to preserve as much as possible for buffer space. Also, I didn't really need any new features. I built a stripped down version based on r15545 and stuck with that. Over time, I backported a few fixes and reduced memory use a bit more. I didn't bother to do anything more official with that because I removed features in a messy way, and I didn't see any demand. I'd love to do the 8 MB hardware mod, but I don't trust myself with that much tricky surface mount soldering, and anyways, things work well as-is.

[TAC109]

I still have a working v1 Archos jukebox recorder 20, with a 40GB drive in it. It runs Rockbox vn 2.5.1 (surprise, surprise). It has been superseded by my 32GB iPhone 3gs, but as I can't fit all my tracks onto the iPhone the Archos still gets used from time to time.

The iPhone features of the inbuilt iPod application plus the Audiomark app (which supplies similar functionality to the Rockbox bookmarking facility) gives me most of the facilities of the old Rockbox.

Last year I installed the current (at that time) version of Rockbox onto my wife's old iPod Photo. I found it rather flaky and unreliable, so removed it.

Rockbox for the Archos was in my (limited) view the best implementation of the Rockbox software.

[saratoga]

In 2007, I stopped updating the Rockbox version I use on there. There's only 2 MB of RAM, and I wanted to preserve as much as possible for buffer space. Also, I didn't really need any new features. I built a stripped down version based on r15545 and stuck with that. Over time, I backported a few fixes and reduced memory use a bit more. I didn't bother to do anything more official with that because I removed features in a messy way, and I didn't see any demand. I'd love to do the 8 MB hardware mod, but I don't trust myself with that much tricky surface mount soldering, and anyways, things work well as-is.

I've been of the opinion for a while now that at some point we should just fork off HWCODEC into it own branch and concentrate on memory efficiency rather then new features.  Otherwise we're going to slowly squeeze out all the 2MB targets.   

[dreamlayers]

I've been of the opinion for a while now that at some point we should just fork off HWCODEC into it own branch and concentrate on memory efficiency rather then new features.  Otherwise we're going to slowly squeeze out all the 2MB targets.   

I've thought similar things. A separate HWCODEC branch may be good for both users and developers. Users would get more efficient and bug free software, and developers wouldn't have to concern themselves with HWCODEC issues while working on the trunk.

[JdGordon]

Hell yeah!
Though the question then becomes at which revision does it get branched? current or many months back?

[Llorean]

Honestly, if I were doing the branch, I'd pick a specific release (3.8, or 3.9.1) and do the branch there since, ostensibly, those ought to be "known good" revisions, but given the amount of testing our releases actually get on that hardware, it might be best to just branch at the current version and let anyone who wants to maintain that hardware roll back changes that are detrimental.

[JdGordon]

Alot of rockboxes customisability could be removed from a hwcodec fork which should reclaim quite a bit of wasted ram. The entire skin engine for example probably isnt needed (anyone really using those older targets probably doesnt care about its looks anyway). ditto icons and a bunch of stuff.

I have no interest in doing that but as usual will gladly help anyone to get it done if they wanted it. (removing skin engine shouldnt actually be too difficult)

[saratoga]

Last I asked amiconn about it, he was not in favor.  However that was some years ago, so he may have different opinions now.  Since he knows hwcodec so well, he should probably agree before people get too excited.

[JdGordon]

I believe that is pretty unlikely.
Apart from the code mess I don't think any features have been rejected because it wasnt possible to handle in an #ifdef-able way for hwcodec, but I'm getting very close to just blowing away all the charcell graphics code (which for me is a far bigger annoyance than HWCODEC per-se) which would possibly mean removing hwcodec anyway.

[dreamlayers]

I looked at memory usage a bit this weekend:

The biggest difference is between a RomBox build without the database, and a normal build. I was able to build RomBox for v2 Recorder up to Rockbox 3.3 by disabling both the database and radio.

For a long time RAM usage doesn't increase that much. For example, unmodified r15545 (the version I based my modifications on) uses 515444, 3.3 uses 522524, and 3.6 uses 525456. However, r30920 uses 644792.

GCC 4.6.2 decreases RAM usage a bit when used with binutils-2.21.1a, compiling with -Os -flto -fuse-linker-plugin and linking with -fwhole-program in addition. Usage went from 644760 to 635228. Unfortunately, it crashes on boot. (Yes, I patched GCC.) To get it to compile I had to modify thread-sh.c and system-sh.c because functions get moved around, so UIE is too far away, and assembly is split into separate files, so asm labels used from C need .global. The modified code still works with 4.0.3.

[JdGordon]

Rasher did a bunch of work building every build ever and checking ram usages.. http://rasher.dk/rockbox/graphs/ that graph is really hard to read but the raw data is there so maybe you might want to generate the graph for just hwcodec?

Like I said before, if you dont care about looks and customisability there is a TON of code that can be stripped (including all the menus!)

[dreamlayers]

Thanks for the link to the graph!

In a list of sizes from rockbox.map, the main things that stand out are the database, skin engine, and unicode.o. However, most of what's used by the skin engine, and the vast majority of unicode.o are bss. I wonder if the new allocation code means these can now be easily allocated from the buffer as needed.

Considering everything except bss, the skin engine still seems like a good candidate for removal. I'm not sure what you mean by stripping all the menus.  Yes, apps/menus uses 11k, but menus are necessary for performing various functions. I guess settings menus could be removed for RomBox, and then settings could be changed by loading a full-featured copy from disc. I'm not sure if that would be annoying.

[gbl08ma]

I no developer nor Rockbox expert, and I don't even own a HWCODEC target, but in the quality of frequent Rockbox user ( ), I'd like to say that I'm in favor of a stripped down version (that would go into a separate branch). This "derivative" of Rockbox could be created from the source of a stable release, and stripped down from there, as some people suggest.

I also suggest that this lightweight version not only applies to hwcodec targets, but to all the targets; why? Well, I feel that for this year and a half that I've been using Rockbox, my player has been constantly loosing buffer ("free") RAM: in May 2009, it was something around 28.7MB, now (build not older than a week) and with the same features enabled (dircache, database), I get 27.3MB or 27.2MB for audio buffer.
I also have the impression the battery life of my iPod has decreased, and Rockbox has a more frequent/intensive memory access (perhaps also because of the audio buffer size decrease).
Buflib, advanced skin engine and everything is very nice, but the fact is that I (and certainly many users, specially those of slower/older targets, like the small Sansa Clips) feel that Rockbox is getting heavier and slower. A version without all the bells&whistles would be greatly appreciated even by me, using a "powerful" iPod Nano 2G.

The removal of the whole skin engine would be really useful both on old Archos and on the recent iPod - at the end, if you always use cabbiev2, does having a skin engine matter much? It's just slowing the device down. And the database and plugins are just taking binary size (important on players where Rockbox is installed to the ROM) if you don't care about them.

Even better if we could dual-boot between the normal and lightweight builds on the targets on which this is possible - but hey, I don't ask for that much!

The lightweight/hwcodec branch would only be updated with "known-good" code that would increase stability over the already existing features, and no new features would be added; some would be even removed (e.g. buflib in the core).
/* Personally, I think RB is much unstable since buflib was ported to the core, but I know it's not a finished work yet (or is it?) */
By other words, this means that hwcodec build would be like frozen in 3.9.1 or 3.8.1 forever; does the hardware still support much more bells&whistles than what these versions provide? If not, then it's better that we stop going forward with fanciness on that target; just freeze it with whatever version it is capable of running with stability, and let's move on to more powerful targets while keeping an eye on the light targets to make sure any remaining bugs with their branch are solved, and that they aren't missing any of the smaller features that can be implemented on them.
Why do you think Windows 7 doesn't run on my PC from 2002, and why do you think my laptop from two months ago runs the latest Windows? The same way, you cannot expect to run the hypothetical future Rockbox 5.2 on a Archos.

Eventually I'm just repeating half of what's been said on this thread; anyways, looking forward to a "Lightbox" to run on my iPod for those times I want 26 hours (or even more, who knows) playback and not a fancy skin, Rockboy or database.

Just my three cents...

[saratoga]

I also suggest that this lightweight version not only applies to hwcodec targets, but to all the targets; why? Well, I feel that for this year and a half that I've been using Rockbox, my player has been constantly loosing buffer ("free") RAM: in May 2009, it was something around 28.7MB, now (build not older than a week) and with the same features enabled (dircache, database), I get 27.3MB or 27.2MB for audio buffer.

According to the chart, during that time RAM usage increased by a few hundred KB, so I suspect a lot of that may be due to things like larger dircache or database, or just enabling dircache at all (it used to be off by default).

The removal of the whole skin engine would be really useful both on old Archos and on the recent iPod - at the end, if you always use cabbiev2, does having a skin engine matter much? It's just slowing the device down.

While I know nothing about the skin engine, I suspect that without it displaying CabbieV2 would be very difficult.

And the database and plugins are just taking binary size (important on players where Rockbox is installed to the ROM) if you don't care about them.

Plugins do not take up binary size (as they are not part of the binary), and you can easily disable the database at compile time if you don't want the code for it (which is not very large).

Eventually I'm just repeating half of what's been said on this thread; anyways, looking forward to a "Lightbox" to run on my iPod for those times I want 26 hours (or even more, who knows) playback and not a fancy skin, Rockboy or database.

You're welcome to test it, but I doubt the difference is going to be more then a few minutes of battery life.  Nothing you've mentioned has more then a trivial impact on power consumption for modern targets.  But sure, by all means if you don't want features and it annoys you that you have plugins installed feel free to strip out whatever you like.  Its pointless, but also harmless. 

[LambdaCalculus]

+1 for dreamlayers' pitch.

I'm not really using my Archos JBR very much either anymore (except as storage for my MP3 library), so forking out all the HWCODEC stuff and keeping Rockbox lean and mean for SWCODEC targets sounds like a good idea.

Perhaps we can start even doing that now that we've forked for 3.10 and keep 3.10 as the final version that will officially support the Archos devices?