Rockbox General > Rockbox General Discussion
Optimizing Rockbox Sources
ant:
--- Quote from: jdgordon on December 31, 2006, 11:12:37 AM ---I think the audio buffer is used as a ring buffer, so the start, end and size are all needed at init.
--- End quote ---
I can't see the problem. Each block has a pointer to the next and the last block and the end is connected to the beginning so it is still a ring.
bk:
--- Quote from: ant on December 31, 2006, 10:59:07 AM ---I have an idea how to implement dynamic memory allocation. It would eliminate at least the issue with the memory pool, so every target would protfit of more avilable ram and in the end longer playtime.
Divide the ram in blocks of say 100kB.
--- End quote ---
So you inevitably would waste a significant portion of 100kb most of the time (partially used block). On some targets with very little RAM (I think ifp only has 1MB total) that's not acceptable.
Decreasing block size would increase your pointer stack overhead, also wasting memory.
Being used to PCs at first I was a little annoyed that malloc is not available in Rockbox. Over time though I began to appreciate the wisdom of this approach. Debugging on embedded targets is difficult enough without having to deal with dynamic allocation issues.
saratoga:
--- Quote from: bk on December 31, 2006, 02:44:23 PM ---
--- Quote from: ant on December 31, 2006, 10:59:07 AM ---I have an idea how to implement dynamic memory allocation. It would eliminate at least the issue with the memory pool, so every target would protfit of more avilable ram and in the end longer playtime.
Divide the ram in blocks of say 100kB.
--- End quote ---
So you inevitably would waste a significant portion of 100kb most of the time (partially used block). On some targets with very little RAM (I think ifp only has 1MB total) that's not acceptable.
Decreasing block size would increase your pointer stack overhead, also wasting memory.
--- End quote ---
#define the block size so that it can be adjusted depending on the total memory available.
Bagder:
No matter how you plan or think this should be done. feel free to write a detailed proposal and I'm quite sure we will shoot it down.
We have this "we need malloc"-argument repeatedly over an over again until the newcomers realize and understand our viewpoint and our reasoning and then we end up again where we started: without malloc or other dynamic memory usage...
Welcome to the world of grumpy old hackers! ;-)
Sentertainment:
--- Quote from: ant on December 31, 2006, 10:59:07 AM ---I have an idea how to implement dynamic memory allocation. It would eliminate at least the issue with the memory pool, so every target would protfit of more avilable ram and in the end longer playtime.
Divide the ram in blocks of say 100kB. Each block can eather be used for dynamic memory allocation or for audio buffering. If you use a simple wps you need less memory for the wps, so more memory is avilable for the audio buffer. The memory is always fully used.
If the user starts a plugin that needs memory, the memory manager grabs a block from the audio buffer that was already played and makes it avilable for the plugin. If playback is still in the first block of the audio buffer the last block of the audio buffer is sacrificed.
--- End quote ---
ya, that would be compiler level....would be inefficient to do that in the level we code in.
(as many others have been saying also)
Anyways, since this topic picked up so fast, I thought I would put in my 2 cents (I was going to wait until I finished planning/figuring me idea)....well....
Here goes, let's say we reserve the memory for the audio buffer right on the spot, it's pretty much static. I haven't looked how the buffer is structured, but if we set limits for everything accordingly...the two shouldn't interfere.
I am aware this adds complexity, but if done properly, the optimization gained would be well worth the effort.
*As for badger's proposal, I do appreciate the way you said that...
I feel I can understand both standpoints...But I am sure some dynamic allocation can be used if programmed properly. In this case, it's obvious I will need to examine the structure of the audio buffer and then I can actually be at a standing point where I could truly say whether it's worth it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version