Rockbox Ports are now being developed for various digital audio players!
I think the audio buffer is used as a ring buffer, so the start, end and size are all needed at init.
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.
Quote from: ant on December 31, 2006, 10:59:07 AMI 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. 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.
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.
The way the RAM works is that on init, the parts that need an unknown amount of ram (dircache, tagcache if loading into ram, some other stuff) all get initialised before audio_init(). once that call has been made it is impossible to call buffer_alloc anymore because the rest of the ram is used for the audio buffer.For things that use heaps of ram but arnt accessed often (like the playlist viewer) can always steal the plugin buffer (512kb on targets with more than 9mb ram iirc) which is usually plenty. Of course, this means that this feature cannot be used while a plugin is running (we have TSR plugins (they are exited, but still running in the background))
and wow, I must say...this topic was meant to be for a broad range of optimizations and we seem to be fixed on this idea of whether or not dynamic memory could be used....
Why do you want to allocate for "the system" dynamically. What buffers that the system currently use, do you feel could be larger?
Reason being is the code can be restructured in such a way that loops wouldn't be needed for commands such as menu_find_free() wouldn't require loops...and possibly not even be needed at all if done correctly.
Page created in 0.078 seconds with 20 queries.