Rockbox General > Rockbox General Discussion

Optimizing Rockbox Sources

<< < (3/6) > >>

JdGordon:
I have been trying to get dynamic memory allocatio into the core for some time, but its not going to happen in the forseeable future (like Llorean said, amiconn is a very vocal opponent to this and Im not really in a position to argue with him.)

The basic points against it are:
- needs a pool to be allocated from (so reducing the available audio buffer). some targets have less than 8mb RAM so we have to be very carefull with what uses it.
- adds code complexity (having to worry about checking the memory actually was alocated)
- waste of time because anything that can be done dynamically can be don statically (although with possibly more RAM usage then needed)
- would mean certain features might not be able to be used on the low mem targets becase there is no RAM for the malloc pool.

As for your other ideas, we look forward to patches.
The best place to actually talk with devs is on IRC or the dev mailing list, and patches go on flyspray.

bluebrother:
I recently talked to a guy working on embedded systems, and he told me dynamic memory allocation is not allowed within that stuff in their company because of security reasons. With dynamic allocation you can always run out of memory and how do you want to catch or display that? Only when using static allocation you can make sure what amount of memory is needed and that this memory is sufficient in all cases. That discussion was regarding the automotive sector, so it's pretty much more critical than in some dap. But I too agree that dynamic memory isn't a good thing on small embedded devices -- it gets really hard to control.

The speed issue is much because of the fact Rockbox currently uses only one CPU on ipods and hasn't optimized. On my h120 it works like a charm and there's nothing sluggish in the menus or while scrolling at all.

Btw, Rockbox is written in C, not C++. While they have some similarities there are also quite a lot of differences someone should be aware of ... especially the view on how things should work.

JdGordon:
And for that reason I agree that rockbox shouldnt have dynamic memory as the defacto memory allocatio scheme in the core. BUT I think it should be used for stuff like the buffers for the wps images, and other "fluff" stuff which dont really affect usablility but they are nice to have (e,.g multiple fonts. If people want more than 1 why should everyone lose audio buffer for that?)

Las note on this tho. rockbox does has a minimal dynamic memory allocation system which can be allocated from BEFORE the audio is initialsed which is probably the compromise, (its only downside is buffers egt allocated in entirety at boot and cannot be deallocated)

ant:
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.

JdGordon:
I think the audio buffer is used as a ring buffer, so the start, end and size are all needed at init.

Navigation

[0] Message Index

[#] Next page

[*] Previous page