Rockbox General > Rockbox General Discussion
How many people still use old Archos devices?
dreamlayers:
--- Quote from: saratoga on November 07, 2011, 05:42:50 PM ---
--- Quote from: gbl08ma on November 07, 2011, 05:32:09 PM ---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.
--- End quote ---
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).
--- End quote ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version