FS#6357 - Changes in codecs memory layout
Opened by Tomasz Malesinski (tmal) - Sunday, 19 November 2006, 20:45 GMT
Last edited by Nils Wallménius (nls) - Monday, 25 October 2010, 09:45 GMT
|
DetailsI attach three patches which change codecs memory layout and save some memory. iFP port doesn't work well yet, so I can't test them throughly. I'll be happy if someone tests them on a better supported target.
The first one puts iramcopy area and bss in the same place. Currently a copy of IRAM data in codecbuf has its own space, which is simply wasted after codec initialization. It also moves memory initialization (copying data to IRAM and cleaning bss) to a separate file codec_crt0.c. Only one variable storing a pointer to codec_api left, it is defined in codec_crt0.c too. Please test in particular if playing two files in sequence in the same and different formats work. The second patch moves the malloc buffer from audio buffer to a free space at the end of the codec buffer. If it happens that the biggest codec in terms of code size is not the most malloc buffer hungry then we could reduce the total amount of memory spent on malloc and codec buffer. The CODEC_SIZE macro should now include the codec buffer size and malloc buffer size. I did not increase it, but it may be required. The third patch implements a simple allocator for the vorbis decoder which allows temporary mallocs. The ogg_malloc function works as before, allocating blocks from the beginning of the malloc buffer and without the possibility to free them. The ogg_tmpmalloc allocates blocks from the other side of the malloc buffer. A sequence of most recently allocated blocks may be freed in this case. This removes the need for big static buffers which don't fit in iFP memory. |
Monday, 25 October 2010, 09:45 GMT
Reason for closing: Accepted
Additional comments about closing: one of these patches were committed long ago and the others have been superceded by changes in svn.
I have not tested the affected plugins, because they don't run on iFP. It would be great if someone tested it. Perhaps I will extend my emulator to support more than 1 MB of memory, then I will be able to run those big plugins in the emulator. For now, I am just waiting for comments.
FS#5796which used to crash.What do we want to do about the others?