How many people still use old Archos devices?

[dreamlayers]

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 chart only shows RAM that's used initially. Allocations during startup use additional RAM, and there are far more allocations than just the dircache.

My 5G iPod currently runs r30834 and has a 27.5 MB buffer. I feel okay with that. If there was a stripped down branch, I expect I'd continue running the trunk on the iPod. 

(However, I do wonder what's using that memory. In rockbox-info.txt, RAM usage is 1272304. The buffer allocations, assuming the numbers need to be multiplied by 4, take up another meg. The PCM buffer plus plugin buffer take one more meg. If starting with 32MB, that would leave 28.8 MB.)

[JdGordon]

in svn skins use quite a bit through the images it loads, backdrops for the video are 153KB each (cabbie loads 2), fonts can be large too.

We should be able to track buflib allocations in a simialr way to the macros I added to track skin buffer allocations which would give us a better understanding of what is using the buffer post boot. Though, on any target with more than 2MB of RAM this becomes irrelevant anyway. (the difference in runtime between 28MB buffer and 27MB would be nothing)

[dreamlayers]

Memory allocations show up in "View buflib allocs" in the debug menu. Each allocation has an associated string. For images, it's the image filename, so they're easy to identify. Numbers ("val:") except the last one need to be multiplied by 4 to get the size. The size of the last item, audiobuf, doesn't seem to mean anything.

[JdGordon]

err, yeah, forgot about that screen
audiobuf just uses whatever is left.

[saratoga]

So its been a while and we still have that red build on the table for the 8MB recorder with no decision about what to do about it.  If we did want to fork HWCODEC, is there any reason to wait?  Are future buflib changes expected to be useful for it?

[JdGordon]

I fear forking hwcodec is something which is not going to go down well. At he very least the dev ml is the correct place t discuss doing it.

[saratoga]

I fear forking hwcodec is something which is not going to go down well. At he very least the dev ml is the correct place t discuss doing it.

I realize that, and I'm not even 100% sure its the best option.  I was going to type up an email summarizing the pros/cons of each alternative after I've looked into it some more.

[talos321]

Jukebox recorder 20 V1 upgraded to 80gb. It is one of the daily builds a few days after  2.5.1. I have it mounted on
a dock in my car somewhat all the time and just usb it every so often from my netbook to keep the music
updated 320 mp3.  Sometimes as a gimmick I plug my bass  guitar with adapter into the line in and play over
the car speakers.  I used to do that over headphones while at work (music shop).

It is fine with me if support for these stopped as they have far surpassed what the original firmware intended.